Transience of .front in input vs. forward ranges

[deadalnix]

Le 05/11/2012 05:42, Jonathan M Davis a écrit :
> 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.
>

That is probably true.

But, whatever the solution, this will be true. So it is better, 
considering this will be true, that the user get correct code.

> 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 isn't the first time the subject pop's, and I have already 
encountered the issue in my own code too (in a rubik's cube solver and 
in compiler code to be precise). We may not have the same coding style 
or code on apps that require different approach, but the problem seems 
real to me.

> 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.
>

Dealing with transient range require care anyway. Bunch of code have to 
be touched, whatever the solution choosen. Most phobos act like .front 
isn't transient and currently just expose undefined behavior.