I'm back

[H. S. Teoh]

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

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher