Lambdas

[CJ-Johnson]

This document proposes a path forward to add lambdas to Carbon. It further proposes augmenting function declarations to create a more continuous syntax between the two categories of functions. In short, both lambdas and function declarations will be introduced with the fn keyword. The presence of a name distinguishes a function declaration from a lambda expression, and the rest of the syntax applies to both kinds. By providing a valid lambda syntax in Carbon, migration from from C++ to Carbon will be made easier and more idiomatic. In C++, lambdas are defined at their point of use and are often anonymous, meaning replacing them solely with function declarations would create an ergonomic burden compounded by the need for the migration tool to select a name.

Associated discussion docs:

• Lambdas Discussion 1
• Lambdas Discussion 2
• Lambdas Discussion 3
• Lambdas Discussion 4

[geoffromer]

Consider presenting this information more like this, instead:

Function definitions have one of the following syntactic forms (where items in square brackets are optional and independent):

fn [name] [ implicit-params ] [tuple-pattern] => expression ;
fn [name] [ implicit-params ] [tuple-pattern] [-> return-type] { statements }

The first form is a shorthand for the second: "=> expression ;" is equivalent to "-> auto { return expression ; }".

implicit-params consists of square brackets enclosing an optional default capture mode and any number of explicit captures, function fields, and deduced parameters, all separated by commas. The default capture mode (if any) must come first; the other items can appear in any order. If implicit-params is omitted, it is equivalent to [].

The presence of name determines whether this is a function declaration or a lambda expression.

The presence of tuple-pattern determines whether the function body uses named or positional parameters.

The presence of "-> return-type" determines whether the function body can (and must) return a value.

That's more abstract, but at least for me, it would make it much easier to see how this design is (and isn't) continuous.

[CJ-Johnson]

Awesome! I added this content right above the part that you highlighted. My reading of it is that these two blocks of text are not mutually exclusive. Do you disagree?

[geoffromer]

I agree they're not mutually exclusive. Personally I don't find the table and examples helpful, but they may work better for other people.

[geoffromer]

I agree they're not mutually exclusive. Personally I don't find the table and examples helpful, but they may work better for other people.

[geoffromer]

I think we should specify this slightly differently:

Suggested change

	**Proposal**: To mirror the behavior of init captures in C++, function fields
	will support nothing-implies-`let` and `var` binding patterns. These will be
	annotated with a type and initialized with the right-hand-side of an equals
	sign. The lifetime of a function field is the same as the lifetime of the
	function declaration or lambda in which it exists.
	**Proposal**: Function fields mirror the behavior of init captures in C++.
	A function field definition consists of an irrefutable pattern, `=`, and an initializer.
	It matches the pattern with the initializer when the function definition is evaluated.
	The bindings in the pattern have the same lifetime as the function, and their scope
	extends to the end of the function body.

This is more general than what we've discussed so far, because it allows things like fn [(a: auto, b: auto) = Foo()] {...}, but that generalization seems desirable.

[zygoloid]

Suppose I want to write this:

let a: String = "long string I'd rather not make a copy of";
DoThingWithLazyGetter(fn [???] => a);

Can a ref capture be used to capture a let binding? If so, what happens -- does that create a temporary and capture a reference to it, or does that capture a value as if by [a: auto = a]?

If not, I think the outcome is that there isn't a way to capture a let binding without renaming it. You can use a function field, but our name shadowing rules would suggest that you must use a new name for the function field. I wonder if it'd be worth adding syntax for capturing a value as a value, rather than as an object.

[zygoloid]

I think we still need an answer here -- I think wanting to capture a local let binding will be a common case, and requiring it to be renamed seems unsatisfying from an ergonomic perspective.

[zygoloid]

This leads question has now been answered: #3860

[zygoloid]

Looks good to me, thanks, and sorry for the slow review cycle!

[zygoloid]

Suggested change

	It is imperative that more work be done in this area to address the erganomic
	It is imperative that more work be done in this area to address the ergonomic

[CJ-Johnson]

Thanks! Fixed :)

[chandlerc]

Very happy with the direction here. A bunch of comments, but they're all focused on the proposal write up, not the specific proposed feature.

[chandlerc]

We have a convention of keeping the abstract in the document and the proposal summary th e same -- I feel like there is a bit of content in each, could you merge them?

[chandlerc]

We should probably merge the content here and the PR description.

[chandlerc]

I understand this and the below are just illustrating where the []s and ()s go, but I suspect we'll want to not accept empty []s at least... Would it make sense to use some pseudo syntax to indicate that there's something inside? Or to have a more examples?

[chandlerc]

Not sure what this section heading means....

(I fear it may be ... too succinct? I'll see myself out.)

[chandlerc]

I think this is just trying to speak to definition syntaxes.

Suggested change

	The presence of _name_ determines whether this is a function declaration or a
	lambda expression. The trailing `;` in the first form is required for a function
	declaration, but is not part of the syntax of a lambda expression.
	The presence of _name_ determines whether this is a function definition or a
	lambda expression. The trailing `;` in the first form is required for a function
	definition, but is not part of the syntax of a lambda expression.

[chandlerc]

Adding some whitespace based on some bikeshed-y discussion in the syntax channel...

Suggested change

	fn[B, C] => A1
	fn(D) => A2
	fn[B, C](D) => A2
	fn { E1; }
	fn -> F { E2; }
	fn[B, C] { E1; }
	fn[B, C] -> F { E2; }
	fn(D) { E3; }
	fn(D) -> F { E4; }
	fn[B, C](D) { E3; }
	fn[B, C](D) -> F { E4; }
	fn [B, C] => A1
	fn (D) => A2
	fn [B, C](D) => A2
	fn { E1; }
	fn -> F { E2; }
	fn [B, C] { E1; }
	fn [B, C] -> F { E2; }
	fn (D) { E3; }
	fn (D) -> F { E4; }
	fn [B, C](D) { E3; }
	fn [B, C](D) -> F { E4; }

[chandlerc]

The alternatives considered are spread throughout the proposal rather than grouped at the bottom which I think makes it a little bit harder to get a sense of what the actual proposal is.

But maybe more importantly, it would be good to try to summarize the pros, cons, and what tipped the scales to not pursue the alternative for each one. That's an important part of the structure we typically want in proposals.

[chandlerc]

As I think Swift is one of the few other languages that has a similar feature, it would be good to a) mention that and b) indicate what if any things really differ between them.

[chandlerc]

Should this also mention only being supported inside the body of another function?

Or, alternatively, in an expression (lambda) or statement (function) context?

[CJ-Johnson]

Made this change to both captures and function fields sections :)

[chandlerc]

Another suggestion for the proposal -- I think it'd be nice to add some comparison for how the Carbon lambdas would look in C++.

This doesn't need to get into features that C++ lambdas have and Carbon's don't, just showing how analogous C++ lambdas would look so that folks can compare.

[KateGregory]

I'm really liking this. A few small comments. More calling examples, ideally right after the first syntax example. "This would be invoked like this:" kind of thing. I see just one (though I may have missed others) example of a lambda not being put into a variable but being used right away, the comparator in the sort example. This is terrific but may be missed by someone less interested in positional parameters, so some other examples of unnamed lambdas just being used would be great. I would hate for a reader to think that the #1 use of lambdas is to put them into a named variable or value.

[CJ-Johnson]

I'm really liking this. A few small comments. More calling examples, ideally right after the first syntax example. "This would be invoked like this:" kind of thing. I see just one (though I may have missed others) example of a lambda not being put into a variable but being used right away, the comparator in the sort example. This is terrific but may be missed by someone less interested in positional parameters, so some other examples of unnamed lambdas just being used would be great. I would hate for a reader to think that the #1 use of lambdas is to put them into a named variable or value.

Thanks for the feedback, Kate! I tried to address it by adding both // In a variable: and // In a function call: variants to the top level examples. Hopefully this will clarify things :)