foreach iterator with closure

[Ali Çehreli]

On 6/28/20 9:07 AM, Denis wrote:

 > * foreach is the actual iterator,

Yes. foreach is "lowered" to the following equivalent:

   for ( ; !range.empty; range.popFront()) {
     // Use range.front here
   }

A struct can support foreach iteration through its opCall() member 
function as well. opCall() takes the body of the foreach as a delegate. 
Because it's a function call, it can take full advantage of the function 
call stack. This may help with e.g. writing recursive iteration algorithms.

 
http://ddili.org/ders/d.en/foreach_opapply.html#ix_foreach_opapply.opApply

 > the instantiation of a struct is the
 > range.

Yes.

 > * When a constructor is not used, the arguments in the call to
 > instantiate the range (in this case, `hello` in letters(`hello`)) are
 > mapped sequentially to the member variables in the struct definition
 > (i.e. to letters.str).

Yes, that is a very practical struct feature. I write my structs with as 
little as needed and provide a constructor only when it is necessary as 
in your case.

 > * When a constructor is used, the member variables in the struct
 > definition are in essence private.

Not entirely true. You can still make them public if you want.

   http://ddili.org/ders/d.en/encapsulation.html

 > The arguments in the call to
 > instantiate the range are now mapped directly to the parameters in the
 > definition of the "this" function.

Yes.

 > * The syntax and conventions for constructors is difficult and
 > non-intuitive for anyone who hasn't learned Java (or a derivative).

C++ uses the name of the class as the constructor:

// C++ code
struct S {
   S();     // <-- Constructor
   S(int);  // <-- Another one
};

The problem with that syntax is having to rename more than one thing 
when the name of struct changes e.g. to Q:

struct Q {
   Q();
   Q(int);
};

And usually in the implementation:

Q::Q() {}
Q::Q(int) {}

D's choice of 'this' is productive.

 > The
 > linked document provides a simplified explanation for the "this"
 > keyword, which is helpful for the first read:
 > https://docs.oracle.com/javase/tutorial/java/javaOO/thiskey.html.

I like searching for keywords in my index. The "this, constructor" here 
links to the constructor syntax:

   http://ddili.org/ders/d.en/ix.html

 > * In some respects, the Java syntax is not very D-like. (For example, it
 > breaks the well-established convention of "Do not use the same name to
 > mean two different things".)

Yes but it competes with another goal: Change as little code as possible 
when one thing needs to be changed. This is not only practical but helps 
with correctness.

 > However, it does need to be learned,
 > because it is common in D source code.

I like D. :p

 > Here is the complete revised code for the example (in condensed form):
 >
 >    import std.stdio;
 >
 >    struct letters {
 >
 >      string str;
 >      int pos = 1;        // Assign here or in this())
 >
 >      this(string param1) {    // cf. shadow str
 >        str = param1;        // cf. this.str = param1 / this.str = str
 >        writeln(`BEGIN`); }
 >
 >      char front() { return str[pos]; }
 >      void popFront() { pos ++; }
 >      bool empty() { return pos == str.length; }
 >
 >      ~this() { writeln("\nEND"); }}
 >
 >    void main() {
 >      foreach (letter; letters(`hello`)) {
 >        write(letter, ' '); }}
 >
 > At this point, I do have one followup question:
 >
 > Why is the shadow str + "this.str = str" the more widely used syntax in
 > D, when the syntax in the code above is unambiguous?

Because one needs to come up with names like "param7", "str_", "_str", 
"s", etc. I like and follow D's standard here.

 > One possible reason that occurred to me is that "str = param1" might
 > require additional GC, because they are different names.

Not at all because there is not memory allocation at all. strings are 
implemented as the equivalent of the following struct:

struct __D_native_string {
   size_t length_;
   char * ptr;
   // ...
}

So, the "str = param1" assignment is nothing but two 64 bit data 
transfer, which can easily by optimized away by the compiler in many cases.

 > But I wouldn't
 > think it'd make any difference to the compiler.

Yes. :)

 >
 > Denis

Ali