DIP 1010--Static foreach--Formal Review

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 12 01:23:58 PDT 2017


On 12.07.2017 01:18, Steven Schveighoffer wrote:
> On 7/10/17 4:53 AM, Mike Parker wrote:
>> As promised, since there has been zero feedback on DIP 1010, "Static 
>> foreach", in either the Draft or Preliminary review rounds, I'm going 
>> to skip the normal two-week feedback cycle on the Formal review. If 
>> there are no major criticisms or objections raised in this thread, 
>> then sometime on Thursday of this week I'll send Walter & Andrei an 
>> email kicking off the decision process.
>>
>> So, if you have any thoughts on the DIP, now is the time to express them.
>>
>> Thanks!
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md
>>
> 
> A few things:
> 
> 1. I can't wait for this to get in. I'm anticipating success :)
> 
> 2. I see no point in having foreach(enum i; 0.. 3) when static 
> foreach(i; 0 .. 3) works just fine?
> ...

foreach(enum i; 0..3) does not currently compile and is not proposed in 
this DIP, but it would be useful for the case where you need an unrolled 
foreach loop.

> 3. The only controversial part I see is that `break` doesn't break from 
> the foreach loop. While I agree with the reasoning, and support that 
> concept, the truth is we currently have a "poor man's" static foreach 
> using a foreach over a tuple, and that DOES break from the loop.
> 
> For instance:
> 
> size_t idx;
> switch(someval)
> {
>     case something:
>        foreach(v; AliasSeq!(1, 2, 3))
>        {
>            if(shouldBreak(v))
>                break; // today, this jumps to moreProcessing() line
>        }
>        moreProcessing();
>        break;
> }
> 
> If I replaced foreach with static foreach(v; 1 .. 4), it now breaks out 
> of the switch?
> ...

Yes.

> As much as I would rather see the proposed behavior, I feel it's too 
> confusing given the existing foreach behavior. I think in this case, you 
> have to require a break label.
> 
> A possible deprecation path:
> 
> 1. In the case where "static foreach" is inside another construct that 
> allows breaking, require a break label. However, foreach over a tuple 
> would continue to exhibit today's behavior.
> 2. print warning message for foreach over a tuple that contains a break 
> without a label. Warn users that a future version will not allow 
> breaking from the foreach.
> 3. disallow breaking out of the foreach directly (i.e. jumping to the 
> closing brace of the loop), even if there is a label (you can surround 
> foreach with a do{} while(false) if you need this behavior).
> 4. Remove the requirement for labeling. Both static foreach and foreach 
> on a tuple do not break from the loop construct.
> 
> -Steve

I don't see why for foreach, break behaviour should depend on the 
aggregate, that is much more confusing. static foreach is not a loop 
with a loop body, it generates multiple versions of the given code. 
There is no reason why static foreach and foreach should have "the same" 
(whatever that even means!) behaviour with respect to runtime break, and 
if it is really considered too confusing, static foreach should just 
always require an explicit label. (But this is painful for me to 
implement, as it is unnatural.)


More information about the Digitalmars-d mailing list