Another thing to object to is: the use of pseudo-generics as type operators. This raises many new problems: including readability problems (how are readers supposed to know that Coffer is a magic fake type, with possibly different rules? If Coffer accepts primitive args, users would be confused that they can say Coffer<int> but not List<int>, etc) and generalized magic-angst (“why can’t I write my own type operators.”).
All that said, I think we’re getting way^3 ahead of ourselves. I still don’t think you’ve adequately outlined what problem you think needs solving; I get that you think it would be not-great to use V? types in public APIs, but it’s a long leap from there to this proposal. > On May 9, 2019, at 10:54 AM, Maurizio Cimadamore > <maurizio.cimadam...@oracle.com> wrote: > > > On 09/05/2019 13:35, fo...@univ-mlv.fr wrote: >> yes, it's verbose by design. > > I object to this a bit. > > There will be cases where using nullable projection will be _the only_ way to > solve certain problems (e.g. to build value types that can reference to > themselves). Forcing an heavy syntax on these cases seems punitive. You seem > to assume that, once we have specialized generics, people will just use them > and forget about nullable projections. I don't think that's the case, and > some internal discussions we started (e.g. to sprinkle values on HashMap > implementation) seem to point in that direction too. > > Maurizio >
