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.

Attachment: signature.asc
Description: PGP signature

Reply via email to