B3, default values, and implicit initialization

[Brian Goetz]

> Despite my initial concerns with the default constructor (primarily 
> how easily a consumer of a class can find this property), I've come 
> around to the "public default Complex()" constructor model because it 
> clearly lets a class's author indicate their intent.  The default 
> constructor should appear as a method in the classfile, though without 
> a Code_attribute, and should be visible to reflection, etc. It's a 
> constructor like any other which also acts as a flag to indicate the 
> author accepts the all-zeros pattern.  Expressing this through the 
> constructor is a clean approach for users and let's us build on 
> existing infrastructure for representing it - similar to how interface 
> default methods benefited from being modeled as regular methods.

Right, it's a clear signal at multiple levels -- source, classfile, 
reflection -- and this idiom works "well enough" at all of them. And 
it's easy to forget the classfile/reflection levels in these discussions.

> My misgivings around the term "default" are due to having already used 
> it to describe interface methods with a default implementation.

Same.  It sometimes feels like "reusing keyword disease", but on the 
other hand, it mostly works.

> The term has also been used related to the default (initial) value of 
> variables but that has no syntax associated with it.  So precedent 
> supports its use..... a mixed result I guess?  ....And I just found a 
> section in the JLS (8.8.9) that already defines the default 
> constructor for a class.  That's even stronger precedent for reusing 
> the term here given this is a slightly different kind of default 
> constructor.

And don't forget annotations...

> We've previously talked about allowing value classes to extend 
> abstract classes.  What are the conditions that would allow my value 
> class to implement a default constructor if it extends an abstract 
> class?  Would the abstract class need a default constructor?  No 
> constructor?  (Probing for the edges of this model to see if it breaks 
> down)

The constructor in a value-capable abstract class is restricted enough 
that it should work file here -- no fields, empty constructor body (save 
for super() call), and such constraints all the way up to Object.

>  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.

One thing we didn't consider completely is a superinterface:

     value class Foo implements Terrible { ... }

We had a discussion about "what does non-atomic really mean" at the EG 
meeting that I now realize I forgot to write up, so I will try to do 
that tomorrow.