I'm back

[H. S. Teoh]

On Fri, Nov 16, 2012 at 10:32:22PM +0100, Jonathan M Davis wrote:
[...]
> Regardless, std.array.array _cannot_ work on ranges with transient
> fronts. So, we have a few options:
> 
> 1. Make transient fronts illegal, then std.array.array and its ilk
> never have to worry about it.
> 
> 2. Make it so that all transient ranges must mark themselves as
> transient.
> 
> 3. Introduce primitives like peekFront to enable ranges with transient
> fronts to work in general while allowing code to assume that front is
> non-transient.
> 
> 3. Attempt to infer transience from the type of front.
> 
> #2 and #3 are too distruptive IMHO and complicate everything. #4 is quite 
> feasible, but it's going to get a lot of false positives, meaning that 
> functions like std.array.array won't work with ranges that they should be
> able to work with just fine. #1 obviously solves all of the problems caused
> by transient fronts, but it means that ranges such as ByLine and ByChunk are 
> illegal (as they currently stand anyway).

Regardless of how we solve it, ByLine and ByChunk need to be changed
anyway. Except for #4, I suppose, but it's very leaky. I wouldn't go for
#4 except as a last resort.


> Personally, I favor making it so that ByLine and ByChunk overload
> opApply and reuse their buffers with it and then make their fronts
> non-transient. It pretty much avoids this whole issue while allowing
> the extra efficiency provided by a transient front in pretty much the
> only common use case that we have for such a range.
[...]

#5 is to document transience prominently and indicate clearly which
range functions are safe/unsafe to use with it. This option requires no
code changes, only documentation changes. It *is* mere coding by
convention, which is generally not desirable, but it does seem to be the
simplest way to allow people to use transient ranges if they know what
they're doing.

#5.1 is to document transience *and* make ByLine and ByChunk
non-transient by default, and provide new transient versions of them for
those people who need to squeeze out every last bit of performance (who
also should know what they're doing so they can't complain if things
break). This way, things are safe by default, yet people can consciously
choose to work with transient ranges.

This may be another approach to balance the need for flexibility and yet
keep things on the safe side by default. 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..


T

-- 
You have to expect the unexpected. -- RL