Optional positional parameters

[gbracha]

The 0.11 spec allows for optional positional parameters, and cleanly separates named parameters from positionals.

[gbracha]

Analyzer issue #4289.
VM issue #4290.
dart2js issue #4291.

[gbracha]

We need to do this in stages.

(1) The first step would be to support the new syntax for named parameters, using {..}. Thus there would temporarily be two ways to specify named parameters.

(2) Then, the libraries could convert to use the new syntax.

(3) After that, the old [..] syntax would be repurposed to support optional positional parameters.

It may be worth breaking the task down into these parts.

[gbracha]

An alternative approach to managing the transition is to implement the complete syntax for both named and optional parameters, but have flag that controls the interpretation. Under the transitional setting, [...] and {..} are interpreted identically under the current rules. This means that callers can still pass positional arguments to named formals. Under this setting, programmers can revise their libraries to use the new named parameter syntax wi/o breaking their callers. Or they can decide that the preferred calling convention should be positional, and retain the [...] syntax. They can fix the callers as best as they can, and then switch the flag off and detect any remaining violations.