Idea how to implement VT/VO compatibility in JVM
Vitaly Davidovich
vitalyd at gmail.com
Thu Jan 22 15:11:55 UTC 2015
Ok, got you. It's detected at runtime just like dereferencing a null or
indexing outside the bounds of an array -- nothing sound about these, but
java's a safe language so has the safeguards.
By the way, the issue of List<T> not being covariant with List<super of T>
was also a drag sometimes in .NET where you knew you weren't mutating the
list and only wanted to read the values (which is safe). So, C# has the
in/out keywords when you define the generic type (only works on interfaces
and delegates) -- compiler then checks your signatures:
https://msdn.microsoft.com/en-us/library/dd469487.aspx and
https://msdn.microsoft.com/en-us/library/dd469484.aspx.
I hate to keep tooting .NET's horn on this list, but I am impressed with
how they've addressed these various issues.
On Thu, Jan 22, 2015 at 9:46 AM, Stéphane Épardaud <stef at epardaud.fr> wrote:
> On 01/22/2015 03:42 PM, Vitaly Davidovich wrote:
>
>>
>> Ok can we first agree that List <T> is NOT List <Object>? :) That's
>> unsound since you can't add any Object in there if things are reified. I
>> think you guys mean List <?>.
>>
>>
>> Well, that what I meant by "variance issues aside". It is unsound but
> detected at runtime. This is already a limitation of List in Java at
> compile-time, I'm not proposing to fix it.
>
More information about the valhalla-dev
mailing list