You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The (most recently) proposed syntax for primary constructors puts type parameters after the name of a named constructor:
// Allow `C.name` to occur together.classC.name<XextendsList<Y>, ... /*lots of stuff*/>(Y y) {...}
This has the advantage that C.name is easily findable and readable, and the constructor name is not split from the class name by a potentially large type parameter list.
However, it doesn't match the call site of the constructor, where type parameters go on the class name, and more worrisome to me, it would conflict with having generic constructors (#647) as primary constructors, where you would want to put a second type parameter list at that position.
I suggest putting the type parameters on the class name, same place they occur in non-primary-constructor classes, and place the named constructor identifier with the parameter list:
// Follow the constructor invocations.classC<XextendsList<Y>, ... /*lots of stuff*/>.name(Y y) {...}
Not a big difference, but still slightly more complicated.
Both options have readability issues, because primary constructors stuff a lot of information into very little syntax, with some of it being used for more than one thing.
Some of those issue are avoided by plain constructors by not having type parameters in the declaration at all (but #1899 would allow that).
The text was updated successfully, but these errors were encountered:
Agreed! I tried out various choices, and ended up with class C.name<X extends B>(args) because it keeps C.name together (such that it can be read at a glance and searched), but it is certainly an unpleasant fact that it conflicts with the call sites for a generic constructor, and differs from a call site for a constructor where we're passing type arguments to the class.
Perhaps we should go even further and simply reject primary constructors on generic classes?
classC<X>.name(X x); // Best case, as proposed here. Really not so bad...classC.name<X>(X x); // Current proposal, clashes with call `new C<int>.name(2)`.
The (most recently) proposed syntax for primary constructors puts type parameters after the name of a named constructor:
This has the advantage that
C.name
is easily findable and readable, and the constructor name is not split from the class name by a potentially large type parameter list.However, it doesn't match the call site of the constructor, where type parameters go on the class name, and more worrisome to me, it would conflict with having generic constructors (#647) as primary constructors, where you would want to put a second type parameter list at that position.
I suggest putting the type parameters on the class name, same place they occur in non-primary-constructor classes, and place the named constructor identifier with the parameter list:
That way the logic is that:
can be rewritten as:
which moves the part of the constructor after
Name
into the class declaration line, just before any extends or implements clause.If we put the name before the type parameters, and the arguments after, it's instead:
Not a big difference, but still slightly more complicated.
Both options have readability issues, because primary constructors stuff a lot of information into very little syntax, with some of it being used for more than one thing.
Some of those issue are avoided by plain constructors by not having type parameters in the declaration at all (but #1899 would allow that).
The text was updated successfully, but these errors were encountered: