Good/Bad? @disable postblit for struct InputRange

[monarch_dodra via Digitalmars-d-learn]

On Friday, 5 September 2014 at 19:55:50 UTC, Nick Sabalausky 
wrote:
> One issue with struct-based input ranges: Saving the state of 
> an input range is not supported (by definition of input range), 
> and yet, you can trivially and accidentally do so with a simple 
> assignment or passing into a function. The results may or may 
> not blow up depending on the exact situation.
>
> And if the input range happens to hit a poorly-implemented 
> algorithm which *should* be statically requiring a ForwardRange 
> and using ".save()" to duplicate state, but instead accepts any 
> range and (accidentally?) saves state by simple struct 
> copy...which will work fine for most struct-based forward 
> ranges and therefore could go completely unnoticed...Then once 
> again, your input range touches it and BOOM.
>
> This *could* be addressed by making the input range a class, 
> but that seems a bit overkill in many cases.
>
> So I'm tempted to give my struct-bassed input ranges a 
> @disable'd postblit. That would solve the problem, right? Would 
> there be any reason NOT to do this?

Ref semantics is one option, yes. Either by class, or by struct. 
For example, most IO ranges implemented ref-counted reference 
semantics.

IMO, disabling postblit is overkill, as almost anything that does 
anything with ranges will pass them by value at one point or 
another.

That said, most of the functions that do operate (and modify) a 
range either take it by reference, or return the modified copy. 
This means you can "boomrang" your range in and then back out. EG:
r = doIt(r);

For example, copy, find etc... do this.

*Ideally*, these functions would do a move-return, and you'd 
pass-by-move, so you'd be able to effectively disable postblit, 
but still pass by move-value. Unfortunately, we aren't quite 
there yet...

My 0.02$