B3, default values, and implicit initialization

[Brian Goetz]

Agreed.  The fact that it looks like a field, but its initial value is 
not actually an expression of that type, is pretty much disqualifying.

But, they syntax is not really the main point here.  Stephen's point is 
that he's worried that "performance lore" will drive people to reach for 
B3, even when the zero-default sucks (like LocalDate).  We can't stop 
developers from being moths to the performance flame, but what we can do 
is try to find the most clear way to represent "instances of this class 
can be implicitly initialized", and have users explicitly opt into 
that.  And we can show what good judgment looks like by leading by 
example in the JDK.  We're good on the "requiring opt in" part, what 
we're mostly debating here is whether a class modifier or field or 
constructor or other special member or supertype is the best way to say 
"implicitly initializable value".

(The field syntax also teases that you can put any value there, but you 
can't.  Which is why the implicit constructor syntax has no body; you 
can't put code in there that would make you think that you get to choose 
the default state.)

On 4/27/2023 2:31 PM, Remi Forax wrote:
>
> I do not find this syntax attractive, especially the "new" in "default 
> = new", i can hear my students saying "new what" ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20230427/03e948cb/attachment.htm>