On Thursday, 30 September 2021 at 02:50:13 UTC, jfondren wrote:

funcs = []

for i in range(0, 3):
    n = i + 2
    funcs.append(lambda: print(n))

for f in funcs:
    f()  # output: 4 4 4

No, in python, variable are not scoped. The semantic is consistent.

You'll note that it generally doesn't matter in python, because there is no notion of immutability or construction/destruction, so both behaviors are acceptable for python.

D either needs to ditch constructor, destruction, immutable, and anything that has to do with lifetime.

On Thursday, 30 September 2021 at 11:00:15 UTC, deadalnix wrote:

I rather have closures that require you to state what you capture.

On Thursday, 30 September 2021 at 11:32:28 UTC, Sebastiaan Koppe wrote:

I really like that in C++ because you don't clutter memory with unnecessary references. Your closure will only reference what you capture.

On Thursday, 30 September 2021 at 00:59:26 UTC, deadalnix wrote:

Yes, that is the semantics I would expect. Note the complication when vars from multiple scopes are captured:

int i = 1;
dgList ~= { writeln(i); };

while (i < 4) {
   immutable int n = i++;
   dgList ~= { writeln(i, " ", n); };
}

Expected:
4
4 1
4 2
4 3

That would require an implementation like this:

static struct __C0
{
    int i;
    void call() { writeln(i); }
}

auto c0 = new __C0(1);
dgList ~= &c0.call;

while (c0.i < 4) {
   static struct __C1 {
      __C0* c0;
      immutable int n;
      void call() { writeln(c0.i, " ", n); }
   }

   dgList ~= &(new __C1(c0, c0.i++)).call;
}

On Thursday, 30 September 2021 at 01:00:40 UTC, deadalnix wrote:

Maybe, idk.

But I don't understand why we can't just do what (for example) C# does.

No var in loop = closure captures the variable
var in loop = closure captures the value of the variable

Sounds to me like a pretty "easy" thing to fix (if one could agree that such a solution would be acceptible)

On Thursday, 30 September 2021 at 13:23:06 UTC, Imperatorn wrote:

Because Walter thinks that duplicating behavior like C#'s and other languages' will result in a huge performance hit, leading users to get very frustrated.

Here's the link : https://forum.dlang.org/post/s83nb0$12rh$1@digitalmars.com

On Thursday, 30 September 2021 at 11:36:01 UTC, bauss wrote:

I have good news for you: the compiler knows what you capture and what you don't, so the only case where in which you'll have unnecessary reference, is if you capture explicitly and mess it up.

On Thursday, 30 September 2021 at 13:26:21 UTC, Tejas wrote:

It is generally not very difficult to do the wrong thing very fast.

In fact, let's just push this idea to the limit and not run any of the code at all. The performance win are humongous. Every single algorithm is now O(1) and terminates in milliseconds.