https://issues.dlang.org/show_bug.cgi?id=14478
--- Comment #10 from Jonathan M Davis <issues.dl...@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. --