I'm back

[Jonathan M Davis]

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:
> > On Friday, November 16, 2012 13:55:31 H. S. Teoh wrote:
> > > I don't like the prospect of having to duplicate parts of
> > > std.algorithm just because I have some code that produces transient
> > > ranges -- I *know* I'm never going to need to use algorithms on them
> > > that can't handle transience anyway. It's Not Nice to be forced to
> > > duplicate code just because an arbitrary decision was made to ban
> > > transience, or just because some leaky type inference decided my
> > > range was transient when it's not, etc..
> > 
> > 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.
> 
> > I have found reference type ranges to be very useful upon occasion to
> > the point that not having them would be a major problem for some code,
> > but if we were to start from scratch, I'd probably still argue against
> > allowing them and just get rid of save entirely, because it's caused
> > us a lot of problems. I really don't want to see ranges complicated
> > even further.
> 
> [...]
> 
> 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.

- Jonathan M Davis