Conversation
|
Tagging @cston @CyrusNajmabadi @gafter for review. |
| Accessibility rules for `private` members in the enclosing scope are the same for `static` and non-`static` lambdas. | ||
|
|
||
| No guarantee is made as to whether a `static` lambda definition is emitted as a `static` method in metadata. This is left up to the compiler implementation to optimize. | ||
|
|
There was a problem hiding this comment.
i agree with this. Should we consider something additional like:
Implementations are recommended to emit a static lambda with a singleton allocation for improved performance
?
There was a problem hiding this comment.
I'm fine to leave that as an implementation detail
There was a problem hiding this comment.
wouldn't that be useful with function pointers?
unsafe class Instance {
void Use() {
delgate*<Instance, string> f = &static i => i.ToString();
f(this);
}
}In the proposal, the recommended workaround for instance methods is to use static local functions. I think a major advantage of using static lambdas over static local functions here is type inference and avoiding typing out the whole signature so it could be of help in this scenario as well.
| A lambdas with `static` cannot capture state from the enclosing scope. | ||
| As a result, locals, parameters, and `this` from the enclosing scope are not available within a `static` lambda. | ||
|
|
||
| A `static` lambda cannot reference instance members from an implicit or explicit `this` or `base` reference. |
There was a problem hiding this comment.
I suspect you intend that such a reference is a compile-time error. Please say that, and identify the sections of the ECMA specification that require modifications.
Championed issue #275
Relates to PR dotnet/roslyn#39121