[Issue 14478] isInputRange failed to recognize some ranges

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Apr 22 20:06:47 PDT 2015


https://issues.dlang.org/show_bug.cgi?id=14478

--- Comment #10 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
Well, having something like Unique in the standard library not work with input
ranges does sound worse, though I've rarely had a need for that sort of thing,
and I'm quite certain that a lot of range-based code copies elements right now
without considering the possibility of elements that aren't copyable.

Even if we _do_ want to make it so that input ranges work with non-copyable
types though, does it make any sense to do so with forward ranges -
particularly when you consider having movable elements? Though that raises the
question as to how well we do with movable elements and forward ranges right
now. I don't think that most ranges have movable elements, but what happens
when a range has been saved and then an element from that range is moved? Does
the saved range still have a copy of it? Since it's supposed to be a copy of
the range, ideally, it would, but realistically - particularly from the
standpoint of a range being a view into a container - I don't see how it could.
So, I suspect that we're really not dealing with the movability of elements
cleanly right now either.

Regardless, I really think that this is the sort of decision that Andrei needs
to be involved in, and I have no idea what his take on it will be. Allowing
non-copyable elements definitely makes things more complicated - particularly
when it involves adding yet another range trait (and we arguably have too many
already) - but I could also see it looking bad if Unique can't work in ranges,
particularly if the STL now works with movable elements and not just copyable
ones.

This is just ugly all around.

--


More information about the Digitalmars-d-bugs mailing list