The idea of implicit vs default

Brian Goetz brian.goetz at oracle.com
Sat Jan 20 23:14:37 UTC 2024



> Understood, and I remember the debates along these lines. But what I’m 
> hoping to suggest - maybe it’s simplistic - is to in no way change how 
> the language/VM implement this feature, but ‘just' describe it 
> differently without introducing a new concept (‘implicit') to the poor 
> developer. Eliminating a keyword and an idea.

Indeed, we tried to do this many times, and came up short every time.  
That's not to say there isn't a way, but we banged our heads against it 
good and hard over a long time.

If you look at my reply to (I think) David on another mail today, you'll 
see that there really are three distinct situations (identity, value but 
not implicitly constructible, value and implicitly constructible) that 
have different treatments and consequences.  So this "extra concept" 
will show up somewhere, its just a matter of where we can put it so that 
it seems least annoying.  We felt that making it a constructor modifier 
"downleveled" its importance compared to making it a class modifier, but 
the concept has to be there somewhere, unless we want to give up on a 
lot of potential optimizations.

There's a reason this has taken so long; the problem has layers of 
subtlety that were difficult to tease apart.  It was almost like a 
Spanish Inquisition sketch: "The chief impediment to flattening is 
identity.  Identity and nullity.  The three main impediments are 
identity, nullity, and initialization safety.  AMONGST our impediments, 
are such diverse elements as identity, nullity, initialization safety, 
and atomicity....

Each time we discovered a new one, we tried various moves: denial, 
lumping, and eventually, acceptance; then began the long slow process of 
normalization.  We *think* we've now gotten things so that each axis is 
independent and is defined as a useful semantic even separate from 
performance, but ... there could still be more turns of this crank.

(And, as a perverse incentive, the more clearly we separate the various 
considerations, the more likely someone is to ask "surely we can get rid 
of X, no?")

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240120/d152f6ed/attachment.htm>


More information about the valhalla-dev mailing list