On Tuesday, 6 March 2018 at 15:23:52 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 March 2018 at 03:21:47 UTC, Nick Sabalausky
The definition of "what is a forward/non-forward range" for
struct-based ranges should have been "is this() @disabled
(non-forward range), or is this() enabled *and* does the same
thing as .save (forward range)?"
I've skimmed through my range-using code, and indeed, very often
I assume that the ranges are copied even without calling .save()
when passing them to Phobos. That works out of the box -- or
maybe I haven't hit the corner cases yet.
The sharpest redefinition of "forward range" would be: All ranges
are struct-based, and a forward range is an input range that
allows copy-construction/assignment. The save() method would not
be part of the definition anymore.
That relies on the design guideline that ranges should be
lightweight views into underlying containers. Here, it seems
natural to design most of your input ranges as forward ranges
anyway. With the redefinition (forward if copyable), forward
ranges arise for free from input ranges. Without such a
redefinition, all range designers must remember to implement
.save(), even though this 4th member function is far less
prominent than the 3 input range methods.