I'm sure if this was changed there would be other interesting behavior, such as arrays being consumed. And suggestions other than

    for(S s; !s.empty, s.popFront())...

Example:

    void main() {
        S s;

        foreach(i; s) {
            assert(i == s.popCount); // Fail
        }

        assert(s.popCount == 10); // Fail
    }

    struct S {
        size_t popCount;

        auto empty() {
            if(popCount > 9)
                return true;
            return false;
        }
        auto front() { return popCount; }
        auto popFront() {
            popCount++;
        }
    }

On 11/07/2011 12:26 AM, Jesse Phillips wrote:
> I'm sure if this was changed there would be other interesting behavior,
> such as arrays being consumed. And suggestions other than
>
>      for(S s; !s.empty, s.popFront())...
>
> Example:
>
>      void main() {
>          S s;
>
>          foreach(i; s) {
>              assert(i == s.popCount); // Fail
>          }
>
>          assert(s.popCount == 10); // Fail
>      }
>
>      struct S {
>          size_t popCount;
>
>          auto empty() {
>              if(popCount>  9)
>                  return true;
>              return false;
>          }
>          auto front() { return popCount; }
>          auto popFront() {
>              popCount++;
>          }
>      }

Expected, s has value semantics.

for(S _s=s; !_s.empty(); _s.popFront()){
    auto i = _s.front();
    // assert(i == s.popCount()); // expected to fail.
}

On Mon, 07 Nov 2011 18:52:19 +0100, Timon Gehr wrote:

> Expected, s has value semantics.
> 
> for(S _s=s; !_s.empty(); _s.popFront()){
>      auto i = _s.front();
>      // assert(i == s.popCount()); // expected to fail.
> }

Yes thank you. I was just hoping to have access to _s inside the loop.

And yeah, it likely would break lots of code. Granted I kind of wish all ranges would be consumed unless specifying save().