On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote: > 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.
auto inp = std.typecons.inputRangeFromForwardRange(fwd); No need to write the algos twice now, but you do have to add a line or two of code to every input range algo. Or force the the user to call the converter function. --bb