Transience of .front in input vs. forward ranges

[Jonathan M Davis]

On Sunday, November 04, 2012 20:20:58 H. S. Teoh wrote:
> What's not to like about this proposal?

It creates massive code duplication all over the place, and it's yet one more 
range concept that everyone has to remember and keep in mind. Remember that 
ranges are supposed to be perfectly writable by the average D user, not just 
Phobos devs. And this complicates them yet further. If anything, we need to 
_simplify_ ranges, not make them more complex (e.g. getting rid of the move* 
functions). And this proposal not only makes them more complex, it ends up 
requiring that a lot more code be written.

Sure, the fact that ranges are non-transient by default reduces the problem, 
but that just means that it's that much less likely to actually be used, 
meaning that we're complicating ranges even further for something that most 
people are going to forget about completely.

I honestly think that you're pushing for an incredibly abnormal use case here, 
and that it's just not worth the extra complication that it requires.

It's bad enough to be stuck trying to support transient fronts with input 
ranges, but input ranges are so useless in general that it may actually end up 
affecting very few functions in reality. Anything like isTransient or transient 
or fastRange affects _everything_, and just because it can be added in piece by 
piece instead of all at once doesn't change that fact. It just allows us to 
spread out the work.

- Jonathan M Davis