value type hygiene

[Maurizio Cimadamore]

On 10/05/18 00:46, Dan Smith wrote:
> (To be clear about my preferred alternative: we introduce Q types as first-class types (applicable to value classes only), update the descriptor syntax, assert QFoo <: LFoo, and ask compilers to use Qs when they want to guarantee non-nullability and allow flattenability. Compilers generate bridge methods (and bridge fields?) where needed/if desired.)
Yes!

To be clear, it seems like we've been before - I recall a rainy Friday 
spent at a whiteboard in Dublin a couple of years ago on this one. As 
you point out there's a tension here: on the one hand, 'just' using 
L-types (at least in method signatures) give you a path, when it comes 
to type-specialization, not to touch method bodies.

On the other hand, if L means "maybe L, maybe Q", clients have no way to 
disambiguate L-code from Q-code - meaning that the 
Q-accepting-method-in-L-disguise will always have to be prepared for 
handling things coming from outside its clean almost-Q-but-not-quite bubble.

Also, with my bridge hat on (having written many of them) I have to note 
that, while Remi is right in saying that having separate descriptors for 
L and Q is *almost* (added by me) equally expressive as having just L 
with a side-channel (e.g. attribute which lists which Ls are Qs), that 
move restricts us a lot in terms of bridg-y move we can make - as, at 
the VM level there's only one true signature (the L one) and you can't 
write a bridge (from where? to whom?). Unless we want to start emit 
bridges that have signature that is identical to the bridged thing - but 
this seems to violate so many constraints that I don't think it's even 
worth mentioning (in fact pretend I didn't write it :-)).


Maurizio