No, it's not boxing.C# has closures too, in the fo...

2009-03-09T05:26:00.000-07:00

No, it's not boxing.
C# has closures too, in the form of anonymous delegats since C# 2.0, and in the form of lambda expressions since C# 3.0. C#'s closure is similar to those in other languages, that it captures enclosing block's environment.

C# compiler implements closures in a few ways, determined by escape analysis.
The compiler checks if the closure captures "this" (that is to say, if it uses any member fields), and/or if it captures any local variables of the enclosing scope.

If the closure captures neither of the two, or to say if all variables used within the closure are bound, then the compiler emits a private static method.
If it captures "this" but no local variables of the enclosing scope, then the compiler emits a private member method.
If it captures any local variables of the enclosing scope, then the compiler builds a compiler-generated nested class (with the name of something like "<>__CompilerGenerated1" to ensure no name collusion is possible). The anything the closure captures gets stored in an instance of the generated class, and the nested function becomes a method of the generated class.

Jonathan, are you referring to "boxing"? That's no...

2009-02-25T10:14:00.000-08:00

Jonathan, are you referring to "boxing"? That's not what I had in mind...

> There may be at least another solution: wrap eac...

2009-02-24T19:08:00.000-08:00

> There may be at least another solution: wrap each referenced variable into an object, and have both the nested function and the surrounding context share the object reference;

That is how C# and VB do it. So far it hasn't caused me too much pain.

Comments on Programming and Debugging (in my Underhøøsen): Reaching Closure...

No, it's not boxing.C# has closures too, in the fo...

Jonathan, are you referring to "boxing"? That's no...

> There may be at least another solution: wrap eac...