On Mon, Feb 12, 2024 at 03:58:50PM +0000, Quirin Schroll via Digitalmars-d wrote:
> Extend `for` to `for (init; prepare; condition; increment) body`.
> 
> The step `prepare` is executed before each check. Ignoring scope, the
> above is lowered to:
> ```d
>     init;
> start:
>     prepare;
>     if (!condition) goto end;
>     body;
>     increment;
>     goto start;
> end:
> ```
> `continue` is also `goto start`.
> 
> Sometimes, you want to execute something before each condition check, no matter if it’s when entering the loop or when looping back.
> 
> D’s best options for that is:
> * Repeat yourself in `init` and `increment`, possibly using a local
> function if the step is more than 1 simple instruction.
> * Use `{ prepare; return condition; }()`. While not a DRY violation,
> this has the disadvantage that you cannot declare a variable in
> `prepare` that’s present in the loop’s `increment` or `body`.

The primary issue here is that the conventional looping constructs (the age-old for, while, do) enter the loop at the top, and exit the loop at the bottom. However, your general loop may exit the loop in the middle. (The other possibility -- entering the loop in the middle -- is equivalent to this case via a simple code rearrangement.)  Therefore, you have this structure:

	loopStart:
		loopBodyBeforeCondition();
		if (cond) break; // loop exit
		loopBodyAfterCondition();
		goto loopStart;

When loopBodyBeforeCondition is empty, you have a while-loop. When loopBodyAfterCondition is empty, you have a do-loop. When loopBodyAfterCondition only contains incrementing code, you have a for-loop (the initialization part of a for-loop technically belongs outside the loop, just before it begins).  However, there is no direct equivalent to the case when neither loopBodyBeforeCondition nor loopBodyAfterCondition are non-empty (and the latter isn't just for incrementing). In such cases, most code resorts to hacks like `while(true)` with manual exit points.

One example of the usefulness of a loop construct that supports the above construct in full generality is the outputing of list delimiters. If we postulate a syntax construct like:

	loop {
		loopBodyBeforeCondition();
	} while(cond) {
		loopBodyAfterCondition();
	}

then, given some range r of items, we can output it with delimiters like this:

	loop {
		writef("%s", r.front);
		r.popFront;
	} while(!r.empty) {
		write(", ");
	}

However, since we don't have such a construct, we have to resort to various hacks, like:

	while (!r.empty) {
		writef("%s", r.front);
		r.popFront;
		if (!r.empty)	// <-- non-DRY
			write(", ");
	}

Or:

	string delim;	// hack: need an extra variable
	while (!r.empty) {
		writef("%s%s", r.front", delim);
		delim = ", "; // hack: lots of redundant assignments
		r.popFront;
	}

Or:
	if (r.empty) return;
	writef("%s", r.front);	// hoist first iteration out of loop body (non-DRY)
	r.popFront;
	while (!r.empty) {
		writef(", %s", r.front); // fold loopBodyAfterCondition into front of loop
		r.popFront;
	}

The asymmetry of these hacks is caused by the underlying non-correspondence between the desired structure of the output (delimiter is placed between every pair of items) and the available structure of looping constructs in the language (none of the existing looping constructs exit in the middle of the loop body).

Having a construct like proposed above solves the problem by making available a construct that has a 1-to-1 correspondence with the desired structure of the output.


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard

On 13/02/2024 6:52 AM, H. S. Teoh wrote:
> One example of the usefulness of a loop construct that supports the above construct in full generality is the outputing of list delimiters. If we postulate a syntax construct like:
> 
> 
> |loop { loopBodyBeforeCondition(); } while(cond) { loopBodyAfterCondition(); } |
> 
> 
> then, given some range r of items, we can output it with delimiters like this:
> 
> 
> |loop { writef("%s", r.front); r.popFront; } while(!r.empty) { write(", "); } |

Oh I quite like this.

```d
do {
} while(cond) {
}
```

```d
foreach(...) {

} while {

}
```

I would use this a lot.

On Tue, Feb 13, 2024 at 01:59:36PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote: [...]
> ```d
> foreach(...) {
> 
> } while {
> 
> }
> ```

The problemm with this syntax is that it looks too much like two consecutive loops:

```d
foreach(...) {
}
while (...) {
}
```

Maybe a better syntax might be:

```d
foreach(...) {
} continue {
}
```

So it becomes clear that the second block is part of the loop.


T

-- 
Chance favours the prepared mind. -- Louis Pasteur