I'm back

[jerro]

On Thursday, 22 November 2012 at 16:05:10 UTC, H. S. Teoh wrote:
> On Wed, Nov 21, 2012 at 10:10:51PM -0800, Jonathan M Davis 
> wrote:
>> On Friday, November 16, 2012 18:09:44 H. S. Teoh wrote:
>> > On Fri, Nov 16, 2012 at 08:52:39PM -0500, Jonathan M Davis 
>> > wrote:
> [...]
>> > > The problem is that supporting transience complicates 
>> > > ranges even
>> > > further, and they're already too complicated. And 
>> > > supporting every
>> > > possible use case is likely to require yet further 
>> > > modifications
>> > > to ranges, complicating them even further. We have to draw 
>> > > the
>> > > line somewhere.
>> > 
>> > Since that is the case, that really only leaves us with two 
>> > choices:
>> > (1) declare transient ranges outright illegal, or (2) make 
>> > all
>> > default ranges non-transient (e.g. ByLine, ByChunk), and let
>> > documentation warn the user that transient ranges may not 
>> > work with
>> > every algorithm.
>> > 
>> > I'm leaning towards (2), because every other option brought 
>> > up so
>> > far sucks one way or another. I know coding by convention is 
>> > frowned
>> > upon here, but clearly, transience is an issue that requires 
>> > human
>> > insight to solve on a case-by-case basis, and no simple 
>> > enforceable
>> > solution exists. Thus, the only choice seems to be to leave 
>> > it up to
>> > the programmer to do the right thing. The redeeming point is 
>> > that we
>> > will make byLine and byChunk non-transient by default, so 
>> > that users
>> > who don't want to care, don't need to care -- the code will 
>> > just do
>> > the right thing by default. We can then provide byLineFast 
>> > and
>> > byChunkFast for people who want the extra performance, and 
>> > know how
>> > to deal with transience correctly.
>> > 
>> > This solution requires no further code changes beyond making 
>> > byLine
>> > and byChunk non-transient by default, which is what you have 
>> > been
>> > pushing for anyway. And it doesn't have any of the drawbacks 
>> > of the
>> > other approaches.
> [...]
>> > If we agree on (2), then ranges will be no more complicated 
>> > than
>> > they are today. The two Phobos offenders, byLine and 
>> > byChunk, will
>> > be non-transient by default. The documentation will warn the 
>> > user
>> > that transient ranges are to be "used at your own risk", 
>> > just like
>> > casting void pointers and other risky language features that 
>> > are
>> > nevertheless sometimes necessary.
>> 
>> I'd agree with #2, except that I don't know where we'd put 
>> warnings
>> about transience. On isInputRange? It certainly doesn't make 
>> sense to
>> put them on every function. At most, it would make sense to 
>> put them
>> where front or popFront is described.
> [...]
>
> I'd put it on isInputRange, since that's where .front is 
> defined.
> Indicate that transient ranges are used "at your own risk" 
> because some
> algorithms will not work correctly.
>
> And optionally, each algorithm that supports transience can be
> documented as such (the assumption being that if something isn't
> explicitly documented to support transience, it probably 
> doesn't).
>
>
> T

What if we did it so that transient ranges would have to define 
transient property (as was previously proposed), and 
isInputRange, isForwardRange and others would get an additional 
parameter allowTransient. The default value of that argument 
would be false, so those templates would evaluate to false for 
transient ranges by default. Then algorithms that can work with 
transient ranges would use
...
if(isInputRange!(R, true))

instead of

if(isInputRange!R)

The algorithms that don't support transient ranges would not need 
to be changed.  Wrapper ranges such as map's result would define 
transient property if the wrapped range defines it.