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?
- Good/Bad? @disable postblit for st... Nick Sabalausky via Digitalmars-d-learn
-
