Generator implements InputRange

[dukc]

Since std.concurrency.Generator is a class already, I made it to implement std.range.interfaces.InputRange without having to call inputRangeObject().

[dukc]

Uh oh, it seems i need to replace that uint index with size_t...

[dukc]

Now seems to work also in 64bit.

[wilzbach]

@dukc: mind the test failures:

Enforce whitespace before opening parenthesis
grep -nrE "(for|foreach|foreach_reverse|if|while|switch|catch)\(" $(find . -name '*.d') ; test $? -eq 1
./std/concurrency.d:1715:        for(; !empty; popFront())
./std/concurrency.d:1718:            if(broken) break;
./std/concurrency.d:1726:        for(size_t i; !empty; ++i, popFront())
./std/concurrency.d:1729:            if(broken) break;
./std/concurrency.d:1836:        foreach(i; 0 .. 10) yield(i);
make: *** [style] Error 1

Also you might want to consider to use the CodeCov extension (or click on the link, or run the coverage locally) as opApply is uncovered.

[wilzbach]

How is this different to the generic moveFront implementation?

    static if (is(typeof(&r.moveFront)))
    {
        return r.moveFront();
    }
    else static if (!hasElaborateCopyConstructor!(ElementType!R))
    {
        return r.front;
    }
    else static if (is(typeof(&(r.front())) == ElementType!R*))
    {
        import std.algorithm.mutation : move;
        return move(r.front);
    }
    else
    {
        static assert(0,
                "Cannot move front of a range with a postblit and an rvalue front.");
    }

[dukc]

Except for the message, no difference. I tried to call it, but the first static if caused infinite recursion.

[wilzbach]

Works well for me:

https://dpaste.dzfl.pl/de6644a70448

[dukc]

First off, we are talking about std.concurrency.Generator, not about std.range.generate. But that code would work with Generator too, in DPaste.

The reason it does not work in Generator: Look the first static if block in moveFront implementation you just posted. MoveFront(generator) calls generator.moveFront if it can find one -the very function I'm defining!

[wilzbach]

Hmm if we have to add opApply to everything that is an InputRange the range concept of "building block" would have somehow failed. Do you know about enumerate and why doesn't it work for you?

[dukc]

I did not think about it. But wouldn't that plant a land mine for maintenance? If somebody adds an opApply implementation using foreach to enumerate(), it would regress Generators opApply because it would recurse infinitely then.

[dukc]

What we could add to avoid code duplication for cases like this, is a template mixin version of opApply() and moveFront().

Edit: Or a generic range template which guarantees in it's spec to forward only primitives and nothing else.

[wilzbach]

If somebody adds an opApply implementation using foreach to enumerate(), it would regress Generators opApply because it would recurse infinitely then.

I am sorry, but I can't follow. How would sth. like this half-pseudo code end in an infinite recursion?

struct Enumerate(R)
{
    R r;
    int opApply(scope int delegate(size_t, ElementType!R) dg)
    {
         int err;
         auto r2 = r.save;
         for (size_t i; !r2.empty; r2.popFront(), i++)
         {
             err = dg(i, r2.front);
             if (err) return err;
         }
         return 0;
    }
}
myGenerator.enumerate.array;

[wilzbach]

See also, e.g. https://dpaste.dzfl.pl/57536541877a

[dukc]

That code won't. But if it's done like (untested, may have errors):

int opApply(scope int delegate(size_t, ElementType!R) dg)
{
         int err;
        static if(__traits(compiles, foreach(i,e;r){})) foreach (i, e; r.save)
        {
              err = dg(i, e);
             if (err) return err;
         } else for (size_t i; !r2.empty; r2.popFront(), i++)
         {
             auto r2 = r.save;
             err = dg(i, r2.front);
             if (err) return err;
          }
         return 0;
}

That, I think, will, because the foreach inside calls the very indexed opApply of R what's using the Enumerate in it's implementation.

[JackStouffer]

goes at the top of the file

[dukc]

Doesn't: there was one already! I removed mine altogether.

EDIT: I read that import wrong. Went messy so i squashed.

[dukc]

I have no idea what those Linux failures are about... Does somebody have ideas?

EDIT: and now it claims all have passed, even when I did no change!?

[wilzbach]

I have no idea what those Linux failures are about... Does somebody have ideas?

-> http://forum.dlang.org/post/bqgywgewtblzpeynrnxu@forum.dlang.org

You can click on "Deprecate" for specific builds, but the auto-tester will also perodically iterate through the entire queue and retest your PR ;-)

[dukc]

@wilzbach @JackStouffer
CircleCI appears, as of writing, to be stuck in it's execution. I've checked back many times, never seeing it completed.

Otherwise, ready for further discussion.

[wilzbach]

CircleCI appears, as of writing, to be stuck in it's execution. I've checked back many times, never seeing it completed.

Yeah I have observed this a couple of times already since the S3 outage this week. Don't worry about it.

[dukc]

@wilzbach I have answered your concerns of the code 5 days ago, let's continue discussion?

[JackStouffer]

@dukc people get around to PRs when they can

Seb is currently off the grid and probably will be for the rest of the week.

[dukc]

Ok. Just wanted to make sure this wasn't forgotten.

[dukc]

This got too old so i close. I will probably reboot it.

[dukc]

link to new pr: #5309