• monkyyy (27/27) Aug 27 spec doesn't define this behavior as far as I can tell
• Steven Schveighoffer (15/42) Aug 27 For a valid `opApply` you need to continue looping as long as the
• monkyyy (8/12) Aug 27 should vs could

monkyyy <crazymonkyyy gmail.com> writes:

spec doesn't define this behavior as far as I can tell

```d
import std;
auto loop(){
	struct foreach_{
		int opApply(int delegate(int i) dg){
			dg(0).writeln;//1
			dg(1).writeln;//2
			dg(2).writeln;//3
			return 3;
	}}
	return foreach_();
}
unittest{
	a: while(true){
	b: foreach(i;loop()){
		if(i==0){break;}
		if(i==1){break b;}
		if(i==2){break a;}
}}}
```

rn I believe you could pretty reasonably overload the behavior of 
break in a crafted opApply to make a 2d iteration

it should be possible to modify ref indexs and other stateful 
things that are tricky with pure ranges

slight errors produce infinite loops tho and this is like the 3rd 
opApply ive ever written, no idea on stable patterns

Steven Schveighoffer <schveiguy gmail.com> writes:

On Wednesday, 27 August 2025 at 20:34:22 UTC, monkyyy wrote:
 spec doesn't define this behavior as far as I can tell

 ```d
 import std;
 auto loop(){
 	struct foreach_{
 		int opApply(int delegate(int i) dg){
 			dg(0).writeln;//1
 			dg(1).writeln;//2
 			dg(2).writeln;//3
 			return 3;
 	}}
 	return foreach_();
 }
 unittest{
 	a: while(true){
 	b: foreach(i;loop()){
 		if(i==0){break;}
 		if(i==1){break b;}
 		if(i==2){break a;}
 }}}
 ```

 rn I believe you could pretty reasonably overload the behavior 
 of break in a crafted opApply to make a 2d iteration

 it should be possible to modify ref indexs and other stateful 
 things that are tricky with pure ranges

 slight errors produce infinite loops tho and this is like the 
 3rd opApply ive ever written, no idea on stable patterns

For a valid `opApply` you need to continue looping as long as the 
delegate returns 0.

If the delegate returns something other than 0, then you have to 
return that value from `opApply`. If you don't, the behavior is 
not defined. Even what the different values do is not defined or 
specified.

If you reach the end of your data that you are looping, and the 
final delegate call returned 0, then you return 0.

How you loop is defined by you. So calling the delegate in 
different ways is OK, but continuing on a non-zero value is not 
valid.

Relevant spec information (see paragraph 5):

https://dlang.org/spec/statement.html#foreach_over_struct_and_classes

-Steve

monkyyy <crazymonkyyy gmail.com> writes:

On Thursday, 28 August 2025 at 00:49:24 UTC, Steven Schveighoffer 
wrote:
 How you loop is defined by you. So calling the delegate in 
 different ways is OK, but continuing on a non-zero value is not 
 valid.

should vs could

The pattern seems to be 1 is a standard break, 2 and greater 
incrementing by 1 other labels in reverse order. I expect 0, 1 vs 
1 could be justified, maybe the compiler does`[offset-result]` 

list of address pointers and outside, *hostile*, changes I think 
this will survive and maybe could've been in the compiler the 
entire time.