It's not safe until it's in the coffer

[Remi Forax]

I would like to propose an alternative to the V? syntax we are currently using for representing an inline class encoded as a L-type.

I propose to use Coffer<Complex> instead of Complex? (with Complex an inline class).

as notice several of us, the V? syntax as several shortcoming:
- as Brian said, using '?' as a character makes a type that mix wildcards and V? syntax hard to parse.
- as John said, using ? is misleading because other languages have use ? to indicate a nullable type but the Ltype of an inline class is an identityless nullable reference (and being an identityless reference is as important as being nullable)
- as i tried to say, the syntax V? means that V? is a supertype of V, so something that should be preferred to V as type of parameters in methods but we don't want to encourage people to write APIs that make heavy use of V? (using the words of Brian).


I think that a good alternative is to introduce a new class named java.lang.Coffer and makes the compiler to erase Coffer<Complex> to LComplex;
with a mechanism named auto-coffering to go from an inline class to its coffer and vice-versa. Note that because auto-coffering is introduced at the same type as inline class is introduced in the lange, we are free to specify whatever semantics we want for overloaded methods that takes a coffer or its corresponding inline type.


Here are the advantage of using java.lang.Coffer
- we can document the exact semantics of a coffer in the javadoc of java.lang.Coffer.
- nullability and being a reference comes from free because it's a classical class from the user POV.
- it's obvious that if you want to call a method on a value type, you have to un-coffer it first which may lead to a NPE at that point.
- because auto-coffering is a conversion, Coffer<Complex> is not a supertype of Complex.

There are two oddities:
- while the class java.lang.Coffer exists, you can not have an instance of Coffer at runtime, so you have these special rules:
  - java.lang.Coffer.class can exist but it can not be instantiated (like java.lang.Void).
  - java.lang.Coffer can not be a raw type and doens't accept any wildcard bounded or unbounded, because we don't know how to erase them.
- Coffer<Complex> is a reified type so
  - instanceof Coffer<Complex> and new Coffer<Complex>[42] are ok.

So the main drawback is that a Coffer is a new kind of type with some very specific rules. 

Rémi