peter.levart at gmail.com
Sun Jan 27 12:27:58 PST 2013
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.
>> 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.
More information about the lambda-dev