www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1010--Static foreach--Accepted

reply Mike Parker <aldacron gmail.com> writes:
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
Jul 16 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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
Jul 16 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 17 2017
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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?
Jul 17 2017
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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?
Jul 17 2017
prev sibling next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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();
Jul 17 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 17 2017
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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
Jul 17 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 18.07.2017 00:44, Andrei Alexandrescu wrote:

 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


https://github.com/dlang/DIPs/pull/87
https://github.com/dlang/dmd/pull/7009
Jul 19 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 17 2017
parent Jacob Carlborg <doob me.com> writes:
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
Jul 17 2017