PROPOSAL: Method and Field Literals

[Stephen Colebourne]

Jesse Wilson wrote:
> Should the type parameters include the declaring type, return type, or
> both? I prefer both.
>   Method<List, Iterator> listIterator = List#iterator();
>   Field<String, Comparator> aToZ = String#CASE_INSENSITIVE_ORDER;

I was only thinking of it being the return type:
   Method<Iterator> listIterator = List#iterator();
   Field<Comparator> aToZ = String#CASE_INSENSITIVE_ORDER;

> Should we support only raw types in type parameters (as Class literals
> do) or fully parameterized types? I believe using the raw types is
> more correct but it will require warnings suppressions in practice.

I was thinking of parameterized

   Method<Iterator<String>> listIterator = List<String>#iterator();
   Field<Comparator<String> aToZ = String#CASE_INSENSITIVE_ORDER;

> If a type inherits a method, which type is valid for the type
> parameter? Consider ArrayList#iterator(), which is inherited from
> AbstractList. Which of these are valid?

By only specifying the return type, you avoid this issue.

>> In summary, the real question with the proposal is whether we can
>> implement member literals independently of method references and
>> closures? The answer is definitely yes if we use the ## syntax, and
>> probably yes if we use #.
> Is there something I should mention in the proposal?

I think the proposal needs to note that a resolution of the potential 
conflict with method reference/eta expansion is required. This could to 
let later changes handle it, to accept method references are boxed, or 
to use a different syntax. Perhaps there is another option too. (I know 
Neal has some concerns on this conflict of syntax)

Stephen