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
