This one weird trick allows you to capture loop variables.

But because this is a separate function, when you close over that lambda, the lambda's stack is independently allocated on the heap for each loop iteration.

This doesn't exactly capture all variables, any variables in the enclosing scope are not duplicated (so it doesn't in effect capture what values were outside the loop body at that point in time). But isn't this the point?

In any case, thought it was interesting, and wondering if anyone's every thought of this before.

There are some lifetime and quality of life issues, but it's somewhat similar to std.parallelism in hooking opApply for nifty gain.

-Steve

I'm a bit sorry I implemented opApply. The conversion of the loop body to a lambda is a tricky beast, and in general such complex rewrites are not a good idea. The language should be straightforward.

On Saturday, October 19, 2024 8:29:53 PM MDT Walter Bright via Digitalmars-d wrote: > I'm a bit sorry I implemented opApply. The conversion of the loop body to a lambda is a tricky beast, and in general such complex rewrites are not a good idea. The language should be straightforward. Honestly, I've always found opApply to be very hard to understand. It's kind of like it's turning the foreach loop inside out, and it just hurts my brain. I'd probably understand it much better if I had to use it all the time, but at this point, I'd only ever use it in cases where ranges didn't make sense - and even then, I'd probably just elect to use a for loop instead of trying to take advantage of foreach. foreach is nice, but writing for loops isn't a big deal IMHO. But for better or worse, we do have opApply, so I have to deal with it at least once in a while when someone else has used it. But such is life. - Jonathan M Davis

On 10/20/24 20:14, Sebastiaan Koppe wrote: > > Nowadays I dislike them because they allocate behind the scene, and you still get this odd foreach behavior mentioned here - which, to be fair, however unintuitive, I believe to be correct given the interplay of features. The odd `foreach` behavior is a long-standing compiler bug. The behavior with `opApply` is indeed the only correct behavior, no interplay of features has to be considered.

On 10/20/24 04:29, Walter Bright wrote: > I'm a bit sorry I implemented opApply. I am not. > The conversion of the loop body to a lambda is a tricky beast, and in general such complex rewrites are not a good idea. The language should be straightforward. > As someone who has also implemented `opApply`, I do think it is quite straightforward. It's just internal iteration with support for multiple ways to exit the loop, encoded using numerical indices.

On 10/20/2024 3:45 PM, Timon Gehr wrote: > As someone who has also implemented `opApply`, I do think it is quite straightforward. It's just internal iteration with support for multiple ways to exit the loop, encoded using numerical indices. That's because you're smarter than I am, Timon. And I'm not joking. I implemented it as a way to deal with visiting each node of a binary tree. Doing that with a range is clunky and unappealing.

On Sunday, 20 October 2024 at 22:45:24 UTC, Timon Gehr wrote: > As someone who has also implemented `opApply`, I do think it is quite straightforward. It's just internal iteration with support for multiple ways to exit the loop, encoded using numerical indices. Do you have any suggestions or insights how we could resolve its rather poor compatibility with the attribute soup?

Forums