The idea of implicit vs default
Jonathan F
livedinsquares at gmail.com
Sat Jan 20 19:43:15 UTC 2024
I know the EG have considered pretty much everything (I’ve followed the
forums all along) but I haven’t seen this discussed yet, so here goes.
It seems to me the novel concept of implicit for constructors may not be
necessary, as (IMHO) it depends on the story that’s told about how fields
are initialised. Can’t we say the following instead? For a value class
Point, if it has the implicit constructor it also has a quasi-static field
Point.default (I think that’s still the plan). I want to say this
constructor only has 2 things special about it: it has no body, and it’s
used to initialise Point.default when the class is initialised. Later,
fields and array elements of type Point! are (notionally) initialised to
Point.default, not by calling the constructor, which seems more like
reality and like how other fields are set to null/0. So there’s nothing
implicit about the constructor itself; and the creation of Point.default
isn’t magic either, it’s like the creation of Point.class or enum constants
- ‘just one of those things’ that happens when a class initialises.
If that makes sense, I’d go for the previous constructor syntax public
default Point(). Meaning simply this is the constructor used for
Point.default. Or maybe even public default-0 Point() if it’s called the
‘zero instance’.
As a separate but related idea: assuming the language has Point.default, it
could be better to have syntax like Point!.default for the object, with
Point.default meaning null (as these value classes will effectively have 2
defaults), and in general T.default for any type, e.g. double.default. That
seems useful in itself, but it would also allow the simple explanation that
a field or array element of _any_ type T gets initialised to T.default.
Even if that’s not workable, it would make me uncomfortable if
Point.default is non-null when a Point field actually defaults to null!
best wishes,
JF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240120/b790a5d6/attachment.htm>
More information about the valhalla-dev
mailing list