Idea how to implement VT/VO compatibility in JVM

[Brian Goetz]

Thanks Vitaly, explicating how things are done on .NET is highly 
constructive, even if we can't just "do what they did."

On the other hand, we've seen some impassioned defense of "I want to 
keep being able to use List<?> (or raw List)" on this list -- and .NET 
doesn't even have an analogue of these types, you have to use generic 
methods to abstract over types.  So while one might find the .NET type 
system "better", we must acknowledge it doesn't provide Java developers 
with the tools they're used to.  (You could argue this is a feature 
rather than a bug; in a world with no existing code or developer 
experience, this might be true, but that's not the world we're in right 
now.)

And this is the essential tension; a solution that retains compatibility 
(not necessarily just with existing code, but people's existing 
expectations of how it works) is necessarily going to result in a 
"worse" language going forward.  There's no magic solution here (though 
there are bad solutions), the art is putting the pain where it is felt 
least.

Anyone who thinks they have "the" answer to this problem obviously 
doesn't understand the problem.  So for those trying to contribute: it 
would be more helpful if, rather than coming at it from an "I have the 
answer" perspective, try something more like "I might have a small piece 
of an answer."  Being in such a mental place is far more likely to 
result in real contribution!

On 1/22/2015 10:11 AM, Vitaly Davidovich wrote:
> 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.
>>