[Issue 14544] isForwardRange failed to recognise valid forward range

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14544

Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |schveiguy at yahoo.com
         Resolution|INVALID                     |---

--- Comment #6 from Steven Schveighoffer <schveiguy at yahoo.com> ---
I don't think this is an invalid bug.

One is allowed to call r.save without parens, even without @property.

The test is supposed to ensure that r1.save's return type is the same as the
original range, but instead is *also* erroneously checking whether it's a
non-property function or not. The check simply is wrong, and it's easy to get
things like this wrong when one is dealing with duck typing (something I'd love
to see fixed).

Consider isInputRange's requirements:

R r = R.init;     // can define a range object
if (r.empty) {}   // can test for empty
r.popFront();     // can invoke popFront()
auto h = r.front;

Neither of r.empty or r.front require them to be @property. This is simply a
bug and needs to be fixed.

I would be in favor of fixing as ketmar described. There shouldn't be a
requirement that you need or don't need parentheses, the only important thing
to check is if you call r1.save, do you get back the same range type. It also
may be important to check whether you can assign it to something else, as that
is the point of forward ranges (i.e., something that returns a non-copyable
struct is going to pass isForwardRange right now if r.save returns by ref, but
will not be useful as a forward range). Ketmar's update will fix this too.

--