oversight with input ranges

[Jonathan M Davis via Digitalmars-d]

On Wednesday, April 22, 2015 02:05:38 ketmar via Digitalmars-d wrote:
> On Tue, 21 Apr 2015 18:30:44 -0700, Jonathan M Davis via Digitalmars-d
> wrote:
>
> > And since isInputRange has guaranteed that elements have been copyable,
> > I think that it's perfectly reasonable that it's been assumed that they
> > would be, and changing that at this point just isn't worth it.
>
> yet disallowing some algorithms on ranges that are (algos) working ok is
> limiting too. fixing `isInputRange` was the easiest way i found to allow
> usage of such algorithms.
>
> another possibility is to check all algo implementations and see if they
> can be used with ranges that have non-copyable elements, and then mark
> them as such, replacing `isInputRange` to newly created trait. this can
> be automated, i believe -- at least checking.
>
> i understand that this will add another trait to the pile, but i believe
> that this will make std.algorithm better, as it will accept more range
> types. from the user POV i don't care about "range definition purity",
> the only thing i see is that std.algorithm is rejecting a perfectly valid
> range, and i'm doing no copies at all -- so i must forget about all
> std.algo niceties and fall back to stupid loops.
>
> i.e. allowing such ranges in std.algo (where appropriate) will be a win
> for end-user. i understand that it will add some support burden, though.
> but it shouldn't be that big, considering that implementations are more
> or less stable now.

An alternative would be to create a range of pointers to the non-copyable
objects and operate on those instead. That may not be quite what you want,
but it should work, and it avoids having to complicate ranges any further
for what amounts to a very uncommon use case.

- Jonathan M Davis