value type hygiene

Maurizio Cimadamore maurizio.cimadamore at
Tue May 15 12:06:32 UTC 2018

I wonder if we shouldn't also consider something along the lines of 
restricting migration compatibility only for _nullable_ value types, 
where a nullable value type is a value whose representation is big 
enough that it can afford one spare value to denote null-ness. So, if 
you want to convert existing legacy reference classes to value types, 
they'd better be nullable values; this way you don't lose any value in 
the legacy domain - nulls will be remapped accordingly (using a logic 
specified in the nullable value type declaration).

It seems like we've been somewhere along this path before (when we were 
exploring the Q vs. L split) - why would something like that not be 


On 15/05/18 01:57, John Rose wrote:
> There are various ways to do detect and report the mismatch:
> 1. Exclude loading the class, on grounds similar to CLC's.
> 2. Fail to fill the v-table slot for Event.timestamp, leading to AME.
> 3. Fill the v-table slot with a null-rejecting version of 
> Client1Event.timestamp.

More information about the valhalla-spec-observers mailing list