RFC: naming for FrontTransversal and Transversal ranges

[Michel Fortin]

On 2009-04-30 15:57:17 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> As predicted by the "range theory" which predicates that a range will 
> never grow, only shrink, slices should always shrink. Growing is a 
> foreign operation for a slice. This is a big problem that goes beyond a 
> need for purity or cleanliness - it's just terrible to have a slice 
> stomping around, and then uncontrollably being rebound elsewhere and so 
> on. People pass slices into functions, functions modify them and also 
> append to them, and depending on the phase of the moon, some updates 
> are being seen in the caller.

I think D slices are a good concept for pointers to a fixed-size array. 
If you write new int[4], you're creating a fixed-size array of four 
ints, and getting a slice to the whole. If you concatenate it with some 
other array, it creates a new one.

As you like to point out, the fun starts when you have arrays of 
mutable elements and want to resize them. If you have an array of four 
elements and write array.length = 5, then you're perhaps creating a new 
one, disconnected from the previous one, and perhaps not. This pose no 
problem if your slice is the only one pointing to the memory block, 
otherwise the results are rather unpredictable.

Well, containers are no better at that. If you have some slices of a 
container and you grow the container you may or may not disconnect all 
your slices (unless you're creating an indirect slice as {container*, 
int start, int end} or course).

Which makes me think that perhaps we could introduce a unique type 
attribute and just forbid growing dynamic arrays unless they are 
flagged as unique. That'd make "unique T[]" behave as the container and 
"T[]" as the slice. And perhaps we could build that on top of the 
concept of uniqueness Bartosz wants to be expressible in D for the 
concurrency model, as he said in his latest post:

> In traditional type systems there is no way to express the requirement 
> that a message passed by reference must either be a monitor itself or 
> behave like a C++ unique_ptr (an object that leaves no aliases behind). 
> This requirement should be expressible in D, allowing the compiler to 
> check for its violations.

<http://bartoszmilewski.wordpress.com/2009/04/26/multithreading-with-d/>

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/