On May 8, 2019, at 3:12 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > I propose to use Coffer<Complex> instead of Complex? (with Complex an inline > class).
So you are giving a name, "Coffer", to the Old Contract. The javadoc for the named type-constructor could describe this contract fully: - array performance profile associated with indirections not inlines - non-tearing indirection-based updates - null in the value set, if the inline type is already null natively - L-descriptors in the JVM (for those who peek) - circularities OK (a Foo can have a field of type Coffer<Foo>) Maybe Indirect<VT> is the right name, then? The effect of doing this would be to make the indirect version of a type VT to look superficially more like a box, at a time when we are trying to downplay boxes. But it's only superficial. The Coffer/Indirect generic is a one-off type constructor, like ? itself. Put another way, matchfix C<.> is just a bulkier syntax for postfix-? As such it would have to be documented in its essence in the JLS, as well as in its javadoc. One consequence of Coffer/Indirect is that it puts a larger distance between the two types than VT -vs- VT? does. In that, it's sort of like Integer-vs-int. But unlike boxes, natural VT operations are not lifted to Coffer<VT>. The difference between VT and VT? is small enough that I (for one) would expect operations on VT to be lifted to VT?. We would also expect a type system relation between VT and VT?. A consequence of bulkier notation is that it's clear that VT <: C<VT> is false. Another is that programmers will think twice before saying C<VT> where VT? could be an attractive nuisance (like the register keyword). So, there are some things to like about this bulky syntax. There are lots to dislike: - it's bulky (bug or feature?) - the nullability is less obvious (but maybe that's not a problem) - it's a one-off that has to be defined in JLS and javadoc both - it will remind us of wrappers, sometimes — John P.S. BTW, would Coffer<?> erase to Object? P.P.S. Must… not… mention… covfefe… argh!!!
