Jason House wrote:
Andrei Alexandrescu Wrote:
Jason House wrote:
I feel like there are too many differences between input and forward
ranges for such a minor difference. Many range functions are written
assuming no side effects on the caller. This can restrict the use of
helper functions. It may be best to make their usage different...
So how do you think we should go about it? Also don't forget that any
ranges should be seamlessly and efficiently treated as input ranges.
Andrei
You won't like my answer!
Like you've already said, the semantics of forward ranges and input ranges are
different. I would argue that forward ranges have value semantics but input
ranges do not. Any function that implicitly assumes value semantics is wrong.
Sadly, overlapping API's makes that all too easy for someone to write bad code
that passes simplistic tests with forward ranges and then fail with input
ranges.
My initial thoughts is that input ranges should have two changes:
1. A different API from forward ranges
2. Be a reference type (AKA class instead of struct)
In short, I disagree with your basic premise of treating the two ranges
similarly.
I don't want to treat them similarly, but we should be able to treat
forward ranges as input ranges. Otherwise, all algorithms that work for
input ranges would have to be written twice.
Andrei
