It is inconvenient that the default value of a formal parameter is constant

[eernstg]

Currently, default values are constant expressions, which implies that it is impossible for a function declaration to use the default value mechanism to specify a non-trivial computation which fills in an actual argument value when it is omitted at the call site.

[eernstg]

One starting point for addressing this request is the reference to Kotlin given in #137.

[kealjones-wk]

I am curious if this issue has been reconsidered/revisited due to the incoming non-nullable types, default values of parameters that are non-nullable would require that any user created classes/types would have to have a const value just to be able to default it. which may not always be possible.

[eernstg]

We have made some changes to the rules about default values for parameters.

In particular, named parameters can be required, in which case there is no need and no permission to specify a default value. This mechanism is a language mechanism, it's taken into account when determining whether one function is a subtype of another one, and hence it is enforced (so it's quite different from the @required metadata which has been around for several years).

Moreover, abstract methods do not have to have a default value for an optional parameter, even when its type is non-nullable, because the run-time semantics will never rely on such default values anyway.

However, this actually doesn't make much difference here: This issue is essentially about allowing default values to be normal expressions in some scope (maybe: the instance or static scope of the enclosing class, or the library scope, depending on where the parameter is declared). Those expressions would then be evaluated at each invocation where the corresponding parameter is omitted.

The requirement that a default value must be assignable to the type of the corresponding parameter remains unchanged, and the requirement that a default value must be specified iff the dynamic semantics may use it also remains unchanged. So the changes that we're introducing along with non-nullable types will just carry over directly to the kind of defaults that this issue is targeting.

[eernstg]

Note that #951 makes a similar request.

[lrhn]

And #429. My comments there also apply to #951.