Please don't restrict access to the companion-type!

[Brian Goetz]

On Jul 8, 2022, at 4:59 PM, Kevin Bourrillion <kevinb at google.com<mailto:kevinb at google.com>> wrote:


I worry about decision fatigue for common cases, but I'm optimistic we have a really good story here now:

1. First you will decide whether your class is a value class. I think this should be as simple as "do you need any of the features identity would provide?"
2. Then you will decide how much you want to expose its value companion type. Is this as simple as "does it feel worth the (nonzero) risk of bogus uninitialized instances floating around?"
3. And, if you know what you're doing, and you really need to optimize heavily, you can make it non-atomic.

So I disagree with the main request (always-public companion types), but I have a few comments/questions on the details.

Yes, and I think #2 is even simpler: is the zero value a valid value, and a useful default.  If so, make it as accessible as the class.  Yes for Complex; no for LocalDate.  You could get more picky on things like Rational (its not a valid value, but the DBZE might provide enough negative feedback, so you might be willing to skate on thinner ice), but that’s for more advanced library developers to consider.




3. Let the compiler treat fields of companion-types like final fields today, i.e. enforce initialization.
If this were possible to do reliably, we would have gone this way.  But initializing final fields today has holes where the null is visible to the user, such as class initialization circularity and receiver escape.  (And a reliable protocol is even harder for arrays.)  Exposing a null in this way is bad, but exposing the zero in this way would be worse, because now every user has a way to get the zero and inject it into unsuspecting (and unguarded) implementation code.

I'd still like to understand what steps we can take to reduce the damage here, even if they're not 100% solutions.

Essentially, this seems to me to be asking: what can the language do to further reduce the risk that an uninitialized value will be used as input into a computation.  Which is a useful (and orthogonal) question.



4. Provide the users with a convenient API for creating arrays with all elements initialized to a specific value.

We explored this as well; it is a good start but ultimately not flexible enough to be "the solution".  If a class has no good default, what value should it initialize array elements to?  There's still no good default.  And the model of "here's a lambda to initialize each element" is similarly an 80% solution.

fwiw, I'll still keep pushing on offering these, if I can somehow. I think it's strange that they (create-and-fill, create-and-setAll) never got added to Arrays by now. It is very nice when the user can isolate themselves from the initialization gap.

Yes, much like the above, this is “what more can we do” about initialization.  The good news is this is a “simple matter of library design.”


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220710/2546e0cf/attachment-0001.htm>