Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei. I've added my summary to the Review section of the DIP, but I'll quote it here in full:

"This DIP was accepted by the language authors. Both Proposal 1 and Proposal 2 were accepted. Evaluation of the suggested future improvements has been put off until some future date when sufficient experience with the implementation has been accumulated.

Regarding Proposal 1, they find it integrates well with the rest of the language and falls within the spirit of D. They see it more as the removal of a limitation than the addition of a feature, and like that it reuses the syntax and semantics of existing language entities (`alias` and `enum`). They see Proposal 2 as the core of the DIP, finding that it is well-motivated and liking that it reuses elements of Proposal 1.

On the whole, they believe that this DIP obeys the rule of least astonishment in that most of the examples work as expected and are easy to understand by lowering to the pre-DIP language. They also say that the examples are a good sanity check to ensure that the feature fulfills its envisioned applications, and that the DIP is exceptionally well written. This should be read as a note to future DIP authors that they will not be wrong to use this DIP as a model."

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md

On 7/16/17 9:10 AM, Mike Parker wrote:
> Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei.

Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei

On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:
> On 7/16/17 9:10 AM, Mike Parker wrote:
>> Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei.
> 
> Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei

What is the resolution of how break statements affect static foreach/foreach?

i.e. this section:

"As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics."

-Steve

On 7/16/17 9:10 AM, Mike Parker wrote:
> Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei. I've added my summary to the Review section of the DIP, but I'll quote it here in full:
> 
> "This DIP was accepted by the language authors. Both Proposal 1 and Proposal 2 were accepted. Evaluation of the suggested future improvements has been put off until some future date when sufficient experience with the implementation has been accumulated.
> 
> Regarding Proposal 1, they find it integrates well with the rest of the language and falls within the spirit of D. They see it more as the removal of a limitation than the addition of a feature, and like that it reuses the syntax and semantics of existing language entities (`alias` and `enum`). They see Proposal 2 as the core of the DIP, finding that it is well-motivated and liking that it reuses elements of Proposal 1.
> 
> On the whole, they believe that this DIP obeys the rule of least astonishment in that most of the examples work as expected and are easy to understand by lowering to the pre-DIP language. They also say that the examples are a good sanity check to ensure that the feature fulfills its envisioned applications, and that the DIP is exceptionally well written. This should be read as a note to future DIP authors that they will not be wrong to use this DIP as a model."
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md

Awesome! Super glad and looking forward to this in 2.076? ;)

-Steve

On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote:
> On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:
>> On 7/16/17 9:10 AM, Mike Parker wrote:
>>> Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei.
>> 
>> Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei
>
> What is the resolution of how break statements affect static foreach/foreach?
>
> i.e. this section:
>
> "As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics."
>
> -Steve

static break & static continue anyone?

On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote:
> On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:
>> On 7/16/17 9:10 AM, Mike Parker wrote:
>>> Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei.
>> 
>> Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei
>
> What is the resolution of how break statements affect static foreach/foreach?
>
> i.e. this section:
>
> "As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics."
>
> -Steve

I think the only reliable way is to not use jumps (goto, break, continue) at all.
E.g. if you want to unroll the following loop:

foreach (x; someRange)
{
    if (x.isSpecial)
        break;

    x.writeln();
}

You would need to guard every statement/declaration:

static foreach (x; someRange)
    static if (!x.isSpecial)
        x.writeln();

Hence why, I believe that we need more powerful range-like algorithms for manipulating alias sequences. Though in case this using what's in std.meta is not much of a stretch, ultimately it becomes repetitive and very verbose when used more heavily and ultimately doesn't offer significant improvement over the code above:

foreach (x; Filter!(templateNot!isSpecial, aliasSeqOf!someRange))
    x.writeln();

(I'm working on a functional programming library which would allow to use the same functions to transform ranges, alias sequences and other reducible/iterable objects, which should make composing alias sequence transformations a bit more easy and scalable.)

Anyway, if you're iterating over homogeneous expression sequences, via DIP1010 you should be able to use std.algorithm and std.range functions directly, since the resulting range would be automatically evaluated at CT and expanded as an expression sequence:

static foreach (x; someRange.filter!(x => !x.isSpecial))
    x.writeln();

On Monday, 17 July 2017 at 12:50:16 UTC, Nicholas Wilson wrote:
> On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote:
>> On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:
>>> On 7/16/17 9:10 AM, Mike Parker wrote:
>>>> Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei.
>>> 
>>> Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei
>>
>> What is the resolution of how break statements affect static foreach/foreach?
>>
>> i.e. this section:
>>
>> "As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics."
>>
>> -Steve
>
> static break & static continue anyone?

break & continue are special case gotos. What would be the semantics of static goto? In C you can skip the initialization of variables via goto. Would you be able to skip declarations via static goto?

On 7/17/17 9:23 AM, Petar Kirov [ZombineDev] wrote:
> On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote:
>> On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:
>>> On 7/16/17 9:10 AM, Mike Parker wrote:
>>>> Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei.
>>>
>>> Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei
>>
>> What is the resolution of how break statements affect static foreach/foreach?
>>
>> i.e. this section:
>>
>> "As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics."
>>
> 
> I think the only reliable way is to not use jumps (goto, break, continue) at all.
> E.g. if you want to unroll the following loop:
> 
> foreach (x; someRange)
> {
>      if (x.isSpecial)
>          break;
> 
>      x.writeln();
> }
> 
> You would need to guard every statement/declaration:
> 
> static foreach (x; someRange)
>      static if (!x.isSpecial)
>          x.writeln();

My concern is that the proposal asked for break to apply to the runtime construct that surrounds the loop. So for instance, break would apply to the switch statement outside the static foreach.

This differs from current static looping (i.e. foreach over a tuple), where break applies to the foreach.

I'm not concerned with breaking out of the loop. I agree that the proposed behavior is the best choice. However, it's confusing given existing behavior that doesn't do that.

-Steve

On 7/17/17 8:38 AM, Steven Schveighoffer wrote:
> What is the resolution of how break statements affect static foreach/foreach?

We initially allowed break and continue to refer to the enclosing statement, but upon further consideration we will make it an error. This allows us to collect more experience with the feature and leaves us the option to permit break/continue later on. I have contacted Timon about the matter. Thanks! -- Andrei

On 2017-07-17 14:39, Steven Schveighoffer wrote:

> Awesome! Super glad and looking forward to this in 2.076? ;)

It's already merged [1] so..., why not :)

[1] http://forum.dlang.org/post/okiuqb$1eti$1@digitalmars.com

-- 
/Jacob Carlborg