Moving from VVT to the L-world value types (LWVT)

[Srikanth]

On Tuesday 13 February 2018 12:02 PM, Srikanth wrote:
>
>
> On Tuesday 13 February 2018 12:42 AM, John Rose wrote:
>> On Feb 12, 2018, at 8:53 AM, Srikanth 
>> <srikanth.adayapalam at oracle.com> wrote:
>>> Hi Frederic,
>>>
>>> A couple of follow up questions below:
>>>
>>> On Monday 12 February 2018 10:02 PM, Frederic Parain wrote:
>>>
>>> [...]
>>>> The current design allows null references for value types, as long 
>>>> as they are not stored
>>>> in a container (field or array) declared as flattenable. This is a 
>>>> significant change from
>>>> previous design. So, casting null to a value class type is now legal.
>>> OK.  This does not call for any change to the specification of 
>>> checkcast in JVMS ?
>>> (I don't know that it does - Just double checking)
>> There might be an option here:  Maybe we could get away with having 
>> checkcast
>> throw NPE if the target class is a value type.  After all, the 
>> checkcast instruction resolves
>> its class operand.  Remember that we *must* allow polluting nulls in 
>> fields which
>> are not explicitly marked as flat, but *only* because of binary 
>> compatibility requirements.
>> We *do not* allow polluting nulls to be stored into arrays, because 
>> arrays *must*
>> resolve their element types before the first array is constructed.  I 
>> think we could
>> put checkcast into either of these two categories:  Allowing 
>> polluting nulls for
>> compatibility, or forbidding them (throwing NPE).
>
> OK, I have raised https://bugs.openjdk.java.net/browse/JDK-8197791 to 
> track this issue from javac side.
> ATM, javac rejects such casts with  error: incompatible types: <null> 
> cannot be converted to ...
>
> I will work on it after the discussion settles down and there is 
> clarity on the course of action.

Experimenting a bit more with this, I see that in the javac land, the 
methods/operations

Types.isAssignable(Type t, Type s) and
Types.isCastable(Type t, Type s)

share the same innards viz, the TypeRelation "isSubtype".

As such, at the type system level it would appear to be 
unsound/inconsistent to allow assignment of nulls to value type 
instances while forbidding cast of nulls to value type instances.

I think they should behave the same way (allow) and any errors issued 
either at compile time or at load/link/runtime need to be on account of 
other decorations/modifiers/annotations influencing the outcome as 
opposed to some choice at the type system level.

I think what javac ought to do is to align with the runtime behavior 
wherever it can discern the same situation at compile time. At the 
moment I am inclined to think casting nulls to value types in and off 
itself should not result in an error, but only (maybe) on a subsequent 
store.

This needs to be weighed on by type system and runtime experts.

Srikanth