I'm back

[Jonathan M Davis]

On Friday, November 16, 2012 19:06:05 Timon Gehr wrote:
> The suggestion is to ban all potentially mutable indirections from
> 'non-transient' ranges. (this redefines what 'transient' means.) It
> cannot be derived that popFront will invalidate stuff just from the fact
> that the type system does not explicitly exclude that any code ever
> modifies it.

The idea behind the suggestion is to attempt to determine transience based on 
the time and assume that it's non-transient if it's not definitively non-
transient. It's not redefining the term transience. It's just that it cannot 
definitively determine transience based on the type alone. By I guess that I
could see how you could think of that as redefining transience.

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).

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.

- Jonathan M Davis