DIP 1010--Static foreach--Formal Review

[Steven Schveighoffer via Digitalmars-d]

On 7/12/17 4:23 AM, Timon Gehr wrote:
> 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.

It's in the DIP, regardless of whether it's critical to the acceptance 
of the DIP. As it's something on the table for W&A to look at, I wanted 
to voice my opinion on it.

> I don't see why for foreach, break behaviour should depend on the 
> aggregate, that is much more confusing.

Perhaps. My point of view is that I'm generally using foreach over a 
tuple to generate switch cases. I always think that the break is going 
to apply to the switch statement, and it gets me every time. In fact, in 
writing this post, I just found a (harmless?) bug in my code:

switch(str)
{
    foreach(n; names)
    {
        case n:
           ...
           break;
    }
    default:
         break;
}

It's harmless because the default case does nothing. But it certainly 
isn't what I should have written!

I think of foreach over a tuple as separate from foreach over a runtime 
type. To me, it's already a different syntax and more akin to static 
foreach. One may argue that static foreach looks just like foreach, and 
so all of them should behave the same.

> 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.)

 From a user perspective, whether I reach for one tool or the other, the 
behavior shouldn't be subtly different. If I'm looking for a tool to 
unroll loops, I can use foreach with a tuple, or static foreach. Both 
should behave the same.

Perhaps the deprecation path should include a removal of straight 
foreach over a tuple working (use static foreach explicitly). This would 
make the distinction even more obvious.

-Steve