PRE-PROPOSAL: Named method parameters with defaults.

[Paul Martin]

Hi,

> I just don't see much value in named parameters without having defaults (or
> using them to choose between overloads, but that would require massive
> changes). Defaults without named parameters does have interesting use cases,
> but withOUT named parameters, you add two extra complications that do NOT
> exist if you force-combine them with named parameters:

I'm particularly interested in using named parameters to help call
constructors or factory methods of immutable classes, where a number
of final member variables need to be set.  The named parameters help
describe the calls, and in this case default parameters would not
necessarily be needed.  Certainly named parameters and defaults affect
similar areas of the language, and might work well together, but I
think that we can also consider them separately (as well as together).
 In particular I consider that named parameters let you achieve
something that is hard to do otherwise (readable lists of mandatory
parameters), whereas default parameters can be achieved with
overloaded methods (delegating to a 'master' method).

> 1) Given: foo("bar");, which of the two parameters is supposed to be "bar"
> and which is supposed to be "foo" if the method sig is:
>
> public void foo(String a = "foo", String b = "bar") {}?
>
> That problem does not arise with named params.

If C++-style default parameters are used, then only default parameters
at the end of the parameter list can be used.  In this example, a
would be set to "bar" and b would default to "bar".  Or with one of
your examples from an earlier thread:

   public named void foo(String arg1, int arg2 = 5, String arg3 = "foo") {}

Then the following call would be an error:
    foo(arg1: "a", arg3: "b");

Only the following calls would be allowed:
    foo(arg1: "a", arg2: 2, arg3: "b");
    foo(arg1: "a", arg2: 2);
    foo(arg1: "a");

This would simplify method selection, and I suppose would be the only
way to do so without named parameters.

Requiring the  use of named parameters could let you use defaults in
the middle of the parameter list, but then you are left with
restrictions on how they can be overloaded and overridden (which might
be more problematic).

> If I'm undervaluing the benefits of named parameters, by all means, fill out
> a proposal yourself and/or edit the one I'll be writing up. Contact me so we
> can work together.

I think that my named parameters proposal (in an earlier thread) still
largely holds, though it doesn't consider default values, and the use
of annotations seems to be contentious (and is certainly not the only
solution), but I think that it potentially requires the fewest changes
to the language.  However, I think that named parameters with default
values and also just default parameter values would also be valid and
useful proposals, and probably provide more functionality at the cost
of greater change required.  In addition, the simpler constructor
syntax mentioned by Howard Lovatt could also be useful (but maybe out
of scope of Project Coin).  There also seem to be a range of ways to
implement named parameters which really be applied to each solution
(annotations, keywords, and named parameters by default).

Therefore, do you know what the real goal of the proposals presented
in this group should be?  Is it to just identify the possibilities and
discover their advantages and disadvantages, or is some consensus also
required?  Should just one (potentially combined) proposal be produced
for named parameters, or should separate proposals be produced for
each variation?  Does the compiler group have any suggestions (Joe
Darcy)?  I'm certainly happy to help in any way (and am enjoying these
constructive discussions).

Paul