Hi,
from the language perspective, one can create a value type using a "value 
class" VT or a nullable value type NVT with the annonation @ValueBased.

The language let you automatically derive
- a nullable value type VT.box from a value type VT and VT.val is equivalent to 
VT.
- a non nullable value type NVT.val from a nullable value type NVT and NVT.box 
is equivalent to NVT.

The problem of this scheme is that it creates aliasing of types, VT and VT.val 
(resp NVT and NVT.box) is the same type for the compiler and as usual if you 
have a language that support type aliasing you have troubles with the error 
messages (basically you need to bookkeep the type given by the user and replace 
the type used by the compiler by the type given by the user when creating an 
error message).

I think it's far simpler to not allow NVT.box and VT.val, at least until we 
talk about primitive types and their current val/box.

RĂ©mi


Reply via email to