Is V? what we need ?

[Maurizio Cimadamore]

I agree, in principle - and I have raised similar points in the past, 
that is:

V ~= int

V? ~= Integer

And have NO subtyping relationship between them; this puts the language 
on a solid footing, where we reuse existing conversion mechanism to 
sequence overload resolution and all that.

I think what pushed us down this path was perhaps the perceived 
usability fall back: e.g.  we can no longer pass a V where a V? is 
expected. But that's not really the case, as you still have assignment 
conversions between the two, which means it would work on assignment 
context and method calls (albeit with lower priority w.r.t  true 
subtypes, which is what we want anyway).

Maurizio

On 01/05/2019 13:57, Remi Forax wrote:
> Brian ask me to make it its own thread.
> so is V? what we need, because i believe we have been a little over our own head on this and loose the sight of what we need for V?.
>
> we need V?
> - to represent the L variation of a Q type.
> - to interact with generics that are not reified.
>
> V? does that but does far more, V? is a super type of V which is dangerous, because people will use it as parameter of function instead of V because it's a super type and works with null.
> Here we are back to a world were every value types may be null.
>
> I believe that the issue is that V? should work as a box and currently V? is to powerful/useful as a box so people will start to use it as a true type.
> - V? should not be a supertype of V
> - you should not be able to call methods or fields on V? (constructor are still allowed), again it should be a box, so the automatic conversions from/to V/V? are fine, but not more.
>
> the moto for V? should be works like an Integer (not more).
>
> Rémi