On Wed, May 20, 2009 at 12:05 PM, dsimcha <dsim...@yahoo.com> wrote: > == Quote from Bill Baxter (wbax...@gmail.com)'s article >> 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 > > But if you make the input range a class as Jason proposed, then: > > 1. Unless it's final, its methods will be virtual (slow). > 2. You trigger a heap allocation every time you want to make this > conversion. (slow)
Maybe, but I don't really agree that input ranges should be forced to be classes. Seems like they should be allowed to be either as long as they support the required methods. Actually that's a good argument for not making a = b part of the Forward Range concept. If you get rid of that one, then Forward Ranges can be either classes or structs too. --bb