RFC: naming for FrontTransversal and Transversal ranges

[Robert Jacques]

On Fri, 01 May 2009 06:26:19 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> 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/>
>

I think you might of misunderstood the concept of a unique/mobile type. If  
you take a slice or a reference of an unique, you null the source. Which  
makes using unique T logically invalid as a container. Also, shared unique  
T can't be converted to shared T. This incompatibility is the whole point  
of having a unique type in the first place, and negates your concept of  
using unique T as containers. And generally, unique T implies shared  
storage, and can not be used for thread-local arrays.

Lastly, what you're trying to fix is a bug in the implementation of arrays  
(see my posts in this thread) and not a bug in the design.