How about this (which is not unlike one of the ideas you proposed earlier for 
pattern declarations):

 - For a value type V with fields f1 .. fn, let the user write a constructor as 
if it were a regular class.  
 - The compiler inserts synthetic blank finals f`1..f`n, and translates 
accesses to to accesses to f`i
 - The compiler requires that all f`i are DA at all normal completion points, 
and inserts { default_value / witfield* } copying from the synthetic f`i locals

Now, a value ctor looks _exactly_ like a ctor in a non-value type with final 
fields.  No new idioms to learn. 

> On May 17, 2018, at 7:40 PM, Maurizio Cimadamore 
> <> wrote:
> On 17/05/18 23:22, John Rose wrote:
>> A Java constructor in a value class will internally use withfield
>> to translate any assignment of the form "this.x = y", and instead
>> of the blank instance being an incoming reference in L[0], the
>> constructor builds a blank value instances out of thin air using
>> vdefault.
> So, if I understand correctly, a classic Java constructor is a void-returning 
> instance method; in the model you propose a value class constructor would be 
> more similar to a V-returning static method (where V is the value to be 
> constructed).
> This is all and well, but I feel that this pushes the problem under the 
> (assignment) rug. E.g. I believe that reinterpreting the meaning of 'this.x = 
> y' inside a value constructor to mean "get a brand new value and stick y into 
> x" would be very confusing, as semantically, there's no assignment taking 
> place. And, semantically, it doesn't even make sense to think about a 'this' 
> (after all this is more like a static factory?).
> Of course you can spin this as reinterpreting the meaning of the word 'this' 
> inside a value constructor - e.g. the new meaning being "the opaque value 
> being constructed"; but that is likely to clash with other utterances of 
> 'this' in the same value class (e.g. in other instance methods - where 'this' 
> would simply mean 'this value').
> Language-wise (and I repeat, it might well be too soon to dive into this), it 
> feels like we're missing a way to express a new kind of a primitive operation 
> (the wither). Without that, I'm a bit skeptical on our ability to be able to 
> express value type constructors in a good way.
> Maurizio

Reply via email to