I'm back

[Jonathan M Davis]

On Friday, November 23, 2012 22:13:17 jerro wrote:
> > It's not worth the extra complication. Every algorithm ever
> > written then has
> > to worry about it (though clearly many outside of Phobos
> > wouldn't bother), and
> > it's yet another thing that anyone writing a range-based
> > function has to take
> > into account. Any function which doesn't take it into account
> > will then end up
> > with wrong and bizarre behavior when it's given a range with a
> > transient
> > front.
> 
> My proposal was that for example isInputRange!R wouldn't compile
> if R was transient. So as long as people used the existing
> is***Range templates, the code that called an algorithm that only
> works with non-transient ranges with a transient range wouldn't
> compile. The functions that do support transient ranges could
> check for isInputRange!(R, true) instead of checking for
> isInputRange!R.
> 
> > To be correct, most range-based functions would have to add
> > template
> > constraints to block ranges which mark themselves as transient.
> 
> If they already use is***Range constraints, they wouldn't have to
> add anything.

So, isInputRange wouldn't compile with any range which declared an enum which 
marked it as transient? If a range doesn't pass isInputRange, then it isn't a 
range in the first place, and it's likely to cause problems if something passes 
isInputRange under some circumstances and not others. Not to mention, trying 
to add a second argument to isInputRange just complicates things.

And regardless of what kind of constraint is used or whether any needs to be 
added, the fact that such a range might exist complicates any and every range 
which is written. Every range must either ignore the possibility of a range 
being transient, or it has to code for it. If much of anything ignores 
transient ranges, then there was no point in having them in the first place. 
And anything which doesn't ignore them just got more complicated.

It's just not worth it.

- Jonathan M Davis