Article: Why Const Sucks

[SimonN]

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 
> (Abscissa) wrote:
>> 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)?"
>
> yeah.

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.

-- Simon