I'm back

[H. S. Teoh]

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.


T

-- 
IBM = I'll Buy Microsoft!