This one weird trick allows you to capture loop variables.

[Richard (Rikki) Andrew Cattermole]

On 20/11/2024 10:43 AM, Ali Çehreli wrote:
> On 11/19/24 8:50 AM, Richard (Rikki) Andrew Cattermole wrote:
>  > On 20/11/2024 5:43 AM, Ali Çehreli wrote:
> 
>  >> I've always thought opApply is one of the most brilliant
>  >> parts of D. It's easy to see the curly braces of the foreach loop as a
>  >> lambda anyway.
>  >
>  > There are other ways to do it, than just giving it a delegate.
>  >
>  > I.e. hidden state struct and then range over it.
>  >
>  > Still on my todo list to look into, as it solves the attribute problem
>  > of opApply also.
> 
> Please also keep in mind, as mentioned elsewhere in this thread, e.g. 
> tree traversal is trivial with opApply but not with ranges. That's 
> because the delegate is there to call regardless of how deeply recursed 
> we are in traversal. With ranges, a range must maintain the state of 
> traversing.
> 
> So, I guess both styles have their strong points.
> 
> Ali

Indeed, its not something I'd consider for normal data structures (I 
think the only place I use them as greedy with recursive calling, is in 
my allocators). It's not a pattern that immediately comes to mind.

In saying that, yeah there are reasons to want opApply in its current 
form, and given the amount of code that uses it already I was never on 
the side of removal :)

In terms of transversal:

```d
struct S {
	DS* ds;
	Node* node;

	ref V front() {
		return node.value;
	}
}

s.front
```

Is no different than:

```d
{
	Node* node;

	del(node.value);
}
```

You have split out the already existing state that's stored in the 
function out of it.

So you can do a ton of what opApply does today with this approach.