value type hygiene

[Maurizio Cimadamore]

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 
workable?

Maurizio


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.