"the last change" for ranges

[dsimcha]

== Quote from Jason House (jason.james.house at gmail.com)'s article
> 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.

Then how would you handle functions that only require lowest common denominator
functionality?  This is true for *a lot* of cases, including some important ones
like finding the mean and standard deviation some object.  (Incidentally, this is
also where iterable comes in, since such a function doesn't even need to care if
the iteration is with ranges, opApply, or the fairy #$()@* god mother, as long as
foreach somehow works.)  You mean to tell me you'd require explicit handling of
both the input range and forward range case separately in these cases?  The day
this happens, I switch to Java because D will have become just as much of an
insanely verbose bondage and discipline language, but with less libraries.