On Fri, 01 May 2009 06:26:19 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2009-04-30 15:57:17 -0400, Andrei Alexandrescu
<seewebsiteforem...@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.
