On Friday, September 21, 2012 15:20:49 monarch_dodra wrote: > #3 > The only thing I'm having an issue with is "save". IMO, it is > exceptionally dangerous to have a PRNG be a ForwardRange: It > should only be saved if you have a damn good reason to do so. You > can still "dup" if you want (manually) (if you think that is > smart), but I don't think it should answer true to > "isForwardRange".
It is _very_ crippling to a range to not be a forward range. There's lots of stuff that requires it. And I really don't see what the problem is. _Maybe_ it's okay for them to be input ranges and not forward ranges, but in general, I think that we need to be _very_ careful about doing that. It can be really, really annoying when a range is not a forward range. > You just don't know what an algorithm will do under the hood if > it finds out the range is saveable. In particular, save can be > non-trivial and expensive... It shouldn't be. It's a copy, and copy's are not supposed to be expensive. We've discussed this before with regards to postlbit constructors. Certainly, beyond the extra cost of having to new things up in some cases, they should be relatively cheap. > QUESTION: > If I (were to) deprecate "save", how would that work with the > range traits type? If a range has "save", but it is deprecated, > does it answer true to isForwardRange? You'd have to test it. It might depend on whether -d is used, but it could easily be that it'll be true as long as save exists. - Jonathan M Davis
