B3, default values, and implicit initialization

[Brian Goetz]

Returning to an old syntaxy topic which is as-yet unresolved.

On 4/24/2023 7:18 PM, Dan Heidinga wrote:
>
>  I really wanted to cram the non-atomic designation on constructors as 
> well but it's not really a property of the instance; rather it 
> describes writes to storage which puts it as a property of the class.  
> Still trying to come up with a better intuition for where this belongs.

Our journey here has been pulled by multiple forces.  On the one hand, 
there are four separate things that you can opt out of, and each of 
these may have consequences for semantics and performance:

  - opting out of identity
  - opting out of the requirement for explicit construction
  - opting out of atomicity
  - opting out of nullability

We've largely decided that the first three are declaration-site 
properties of the class and the last is a use-site declaration (there 
are of course pros and cons of moving the boundary.)  We've also decided 
that we don't want to lump any of these; each of these is a decision 
that should be made explicitly.

The three declaration-site properties build on each other; non-atomicity 
makes little sense for identity objects, and while I could imagine a 
sensible semantics for implicit construction of identity objects, it's 
just not that useful.  So in practice we'll see one of the following:

    __value class Foo { }
    __implictly-constructible __value class Foo { }
    __non-atomic __implicitly-constructible __value class Foo { }

Stacking modifiers up like this has several disadvantages.  It gets 
annoying fast.  You can't use some modifiers without using prerequisite 
modifiers.  And all the modifiers feel a little "front-loaded."

The other approach, which we considered and rejected eralier, is having 
three different top-level things (call them B1 class, B2 class, and B3 
class.)  This seemed out of line, as it seems better to focus on the 
commonality rather than the differences.

I think we were very successful with moving __implicitly-constructible 
to a constructor; this reframes __implicitly-constructible as a property 
of the class, and making the implicit value a constructor feels 
natural.  That whittles down the "long list of modifiers" from three to 
two, which is progress. It feels like non-atomic might similarly want to 
be "demoted" somewhere syntactically.

Possibilities include:

  - A modifier like non-atomic
  - A modifier on some other class member, such as the constructors or 
the fields
  - A supertype
  - Some other declaration in the class

We test-drove the modifiers-on-constructor idea and it didn't feel 
right; inventing a new kind of declaration in the class also doesn't 
seem right.  So I'd like to test-drive the supertype idea.

In an early version, we actually did model this as a supertype, which we 
called Tearable (or maybe it was NonTearable.)  But I think we can agree 
that the T-word isn't quite the right focus.

What seems like the right focus is a description about the _boundary of 
the object_.  Ordinarily, an object has integrity; the fields travel 
together.  A non-atomic object is a looser confederation of fields; we 
are explicitly saying "the fields can take separate routes to their 
destination."

I am thinking of something like:

     value class X implements WeakValue { ... }

where "WeakValue" means that the object is a weak confederation of its 
fields.  (A WV value class would require an implicit constructor, as 
today with non-atomic.)

(One advantage of using a marker interface like this is that in the IDE, 
the user can navigate into WeakValue and see an explanation of what this 
means in the WV Javadoc.)

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