"the last change" for ranges

[dsimcha]

== Quote from Bill Baxter (wbaxter at gmail.com)'s article
> On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at 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

On a broader note, I think that people need to understand that, just as a free
society can never be a perfectly safe society, a language that allows programmers
the freedom to create concise, general and efficient constructs can never be a
perfectly safe language.  Yes, we could make D as safe as Java, but then
programming in D would be like programming in Java--an exercise in superfluous
verbosity and getting around the language's rigidity.