FWIW, Dan has brought me around to “implicitly constructible value class” as my preferred way (so far) to describe a B3 class.
On Apr 27, 2023, at 2:54 PM, Brian Goetz <[email protected]<mailto:[email protected]>> wrote: 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" ?
