Lambdas with implicit type parameters
daniel.smith at oracle.com
Wed Feb 20 13:24:15 PST 2013
On Feb 20, 2013, at 2:13 PM, Robert Field <Robert.Field at oracle.com> wrote:
> You are right to keep the feature budget in mind. So, the question we always asked ourselves when we were doing FX is, and so the question I'm asking you: if we left things as they are, would we be constrained against doing things the way we (may) want in a future release? That is, are we painting ourselves in a corner by leaving it? If not, keeping it simple is a win.
Good question. In this case, no, there is no pressure to get this "right" now. We can always take the small step of inferring type parameters later*, or the big step of adding syntax for type parameters -- given that we wouldn't want to change the current lambda syntax in any case.
(*Statements like this ignore the fact that speculative checking of lambdas relies, in certain corner cases, on errors that occur in the body. Strictly speaking, from 8 onward, a typing-related language change that eliminates an error from a program will usually be source-incompatible. But I think we've decided the corner-case source incompatibilities there will always be something we're willing to tolerate.)
More information about the lambda-spec-experts