Good/Bad? @disable postblit for struct InputRange

Nick Sabalausky via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Sep 5 12:55:13 PDT 2014


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?


More information about the Digitalmars-d-learn mailing list