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.
