Let's get the semantic around closure fixed.

[Ola Fosheim Grostad]

On Tuesday, 18 May 2021 at 20:26:26 UTC, Steven Schveighoffer 
wrote:
> So basically, depending on when you call the delegate, the 
> thing could be invalid. Not a big deal (maybe?) for a boolean, 
> but could cause real problems for other things. And the user 
> expectation is that when you capture the variable, it's how it 
> was when you captured it. At least it should live as long as 
> the delegate is alive, no?

Yes, OO languages usually dont have destructors, so... Hm. I 
could see how this can go wrong, what if the captured object was 
"made" from an object in an outer scope that assumes that the 
inner scope objectrd is destructed before its lifetime is up?

I think it helps if we forget about stack and think of scopes as 
objects on a GC heap with links to the parent scope, they are 
kept alive as long as they are reachable, then destructed. But 
then we need to maintain the destruction order so that inner 
scopes are destructed first.

(what I meant in my previous post was that I need to experiment 
with delegate parameters and see hownit prevents stuff from 
escaping to fully grok it :-)