Add lambda expression proposal.

[csyonghe]

No description provided.

[CLAassistant]

All committers have signed the CLA.

[tangent-vector]

This is a great proposal to see. It is very encouraging when cutting-edge GPU capabilities are helping to drive the push for Slang to adopt more and more "grown-up" language features, like closures/lambdas.

[tangent-vector]

We should find a chance to "bikeshed" the nomenclature we will use for this feature, without letting it bog down the implementation or proposal process.

The term "lambda" here is, I assume, largely due to the influence of C++ (although I'm aware it has a lot of other precedent). Other terms that should be considered include:

• "closures" / "closure expressions"
• "anonymous functions" / "anonymous function expressions"
• "function expressions"

[tangent-vector]

Thank you for making those edits.

For anybody following from the sidelines, this proposal is a good example of how to cover the major issues, without going into too much detail, for a proposal where the implementation is still ongoing.

[jeffbolznv]

If there is a functional or language interaction reason for this restriction it would be nice to explain it. Or if it's just to reduce the scope of the initial implementation, that's also good to know.

[csyonghe]

There is just to keep the initial scope small. There isn't a fundamental reason why we can't allow mutable captures, especially when targeting SPIRV/Metal where pointers are available.

[jeffbolznv]

Are all accessible values captured? Is there any way to write a "pure" lambda?

[csyonghe]

Values are captured on-demand. Unreferenced variables are not captured. To write a "pure" lambda, just make sure the lambda doesn't reference any local variables or parameters in the outer function.

[jeffbolznv]

Are all types copyable/assignable in slang? Or if it's not, would trying to use its value in the lambda lead to a compile error?

[csyonghe]

RayQuery and HitObject types are currently not copyable, and use of these in the capture will lead to a compile error.

[Devon7925]

Is there a reason why the whole object has to be captured? Seems like this could lead to users accidentally making expensive copies when working with large structures.

[csyonghe]

The decision to capture whole object ensures semantic consistency, so there is never confusion on situations such as:

struct Obj { int a; int b; };
int ar[10];
Obj o;
var lam = () =>
{
     f(o);   // captures o, obviously
     g(o.a);  // do we capture another copy of o.a or reuse o?
     ar[0]; // capture 0-th element or entire array?
     ar[i]; // what do we do?
};

By saying we always capture the root object at all access chains, none of above ambiguous/difficult cases will ever arise.

The redundant context can be cleaned up very easily in an IR pass post initial IR lowering. Spirv-Opt and most drivers are capable to clean this up today, so it is unlikely going to cause severe performance problems.

If performance is ever a concern on some extreme edge cases, the user can always store the value into a local variable first, and then refer to that local variable within the lambda.