https://issues.dlang.org/show_bug.cgi?id=14544
Steven Schveighoffer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |[email protected] Resolution|INVALID |--- --- Comment #6 from Steven Schveighoffer <[email protected]> --- 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. --
