On Wednesday, 8 April 2020 at 23:25:09 UTC, Steven Schveighoffer wrote:
> This works, because it captures the i value as a new variable in a closure, so `val` remains constant while `i` increments.
>
> -Steve

Whooops... that was a major brain fart :(. Sorry for stealing your time.

Still, this makes me think about the rules for accessing variables in the outer frame in lambdas. I guess I'm used too much to the C++ rules that require explicit capture of everything and default to copying. At least @safe code should require explicit capture. There is no guarantee that a lambda is executed in the same thread.

On 4/8/20 8:20 PM, Gregor Mückl wrote:
> On Wednesday, 8 April 2020 at 23:25:09 UTC, Steven Schveighoffer wrote:
>> This works, because it captures the i value as a new variable in a closure, so `val` remains constant while `i` increments.
>>
> 
> Whooops... that was a major brain fart :(. Sorry for stealing your time.

No worries, I didn't spend too long on it.

> Still, this makes me think about the rules for accessing variables in the outer frame in lambdas. I guess I'm used too much to the C++ rules that require explicit capture of everything and default to copying. At least @safe code should require explicit capture. There is no guarantee that a lambda is executed in the same thread.

Yeah, there is a lot of things we could possibly do to prevent these things. I don't know if they are doable without major breakage elsewhere.

I had thought of a capture utility function, maybe that can help in cases like this.

-Steve