enhanced type-inference

[Peter Levart]

On 01/27/2013 07:32 PM, Brian Goetz wrote:
>> Very nice, indeed. Congratulations!
>>
>> We now hardly need casts if APIs are written correctly.
>
> What do you mean by "correctly"?  Obviously "no overloading at all" 
> would help, but that's a pretty big departure from where Java has 
> been.  (Some other languages that rely heavily on type inference 
> prohibit overloading except on arity, for that reason.) Do you have 
> other practices in mind that will help here?
Well, "correctly" in this context means in a way that does not cause 
ambiguities for method resolution when used. I imagine now that we have 
lambda expressions and new inference rules, best practices for designing 
lambda-friendly APIs will be quickly established. One area that the 
Streams API already explored was that subtyping among functional 
interfaces is not always a good idea.

Regards, Peter

>
>> One idea that might make the remaining needed casts more concise, but I
>> don't know how it would play with this new inference scheme, is a kind
>> of "diamond cast".
>
> Yes, this is a promising idea.  We've discussed this internally a 
> number of times but it was always a lower priority than other 
> features. Similarly, "partial diamond", where you only provide enough 
> information to "unstuck" inference, rather than "all or nothing", 
> could make explicit type information more compact.  This could help 
> not only with diamond or the diamond cast idea, but also with explicit 
> type witnesses.
>