Lambdas with implicit type parameters

Dan Smith daniel.smith at
Wed Feb 20 13:24:15 PST 2013

On Feb 20, 2013, at 2:13 PM, Robert Field <Robert.Field at> wrote:

> Dan,
> 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 mailing list