[Checkers] romaybe => ropoly?

[Michael Ernst]

Mahmood-

> It seems that all  
> checkers could actually benefit from polymorphism over type  
> qualifiers, and not just IGJ and Javari.  Specifically, in the case of  
> method whose return type is dependent on the method arguments (e.g.  
> consider: @Poly X getSame(@Poly X x) {return x; }).
> 
> Do we have a sense on how much Interned and NonNull need something  
> like this?

You are right that all could benefit, and in the long run it would be nice
to have uniform support.

I have been on the lookout for places that Interned needs polymorphism
this, and have been slightly surprised that there haven't been a lot of
cases.  (Not enough for me to demand it from Matt.)  More may arise,
though.

> We might consider adding a more generic Poly annotation to the  
> framework.

This a reasonable idea, and I had thought of it as well (with the same
name, even).

I'm slightly reluctant to generalize yet because I is don't @Poly might not
fit well into all type systems.  I don't want to standardize on something
that may not be the right thing in the long run, and I want to keep us
focused on the most important problems now.  I concede that this may not be
a good reason:  perhaps I am being overly cautious, and the benefits
outweigh the costs.

> Can extend Poly to mean Javari's RoMaybe and/or QReadOnly?  
> 
> P.S. Currently, one can template using generics (e.g <I extends  
> @Nullable X> I getSame(I x) { return x; }), but it is quite in-elegant  
> and it doesn't actually mean the same thing, as idealy it would be <T  
> super @NonNull X extends @Nullable X>).

RoMaybe/RoPoly means something different than either of these two things.
The latter one corresponds to QReadOnly, but RoPoly is different than
QReadOnly.  It's a different question whether we want to incorporate the Q*
generics keywords into the framework; that would have its own benefits and
drawbacks.

                    -Mike