First Draft: opUnwrapIfTrue

[Quirin Schroll]

On Wednesday, 16 September 2026 at 14:15:12 UTC, Paul Backus 
wrote:
> On Wednesday, 16 September 2026 at 10:50:10 UTC, Quirin Schroll 
> wrote:
>> On Thursday, 26 February 2026 at 16:01:22 UTC, Paul Backus 
>> wrote:
>>> A better solution would be to redesign your API to combine 
>>> the check and the access into a single operation, either with 
>>> a higher-order function like […] an `opApply` overload:
>>
>> This is why I think we need loop-else. The idea is simple: A 
>> loop-else runs if the loop had no iteration through its body. 
>> An `if` would then, effectively, be a special case of a loop 
>> that runs once if the condition is true and doesn’t run if 
>> it’s false.
>
> I would be hesitant to add a feature with the same syntax as 
> Python's [loop `else` clause][1], but the exact opposite 
> meaning.
>
> [1]: 
> https://docs.python.org/3/tutorial/controlflow.html#else-clauses-on-loops

If I understood correctly, in Python, `break` skips the `else` 
part of a loop, which is quite redundant with `goto` being part 
of D. I don't use Python at all (I tried and I hated every second 
of it), so I don't even know if it has `goto`. Using `goto` like 
this isn't confusing or difficult to get right, and also leaves 
open the option to use `break` in the loop.

A loop `else` that executes exactly if the loop wasn't entered is 
much more useful because it can't be replaced straightforwardly 
by a simple instruction. It needs a setup and the pattern must be 
recognized by the reader; following the pattern also isn't 
trivial, one can get it wrong quite easily.