.NET on a string

dsimcha dsimcha at yahoo.com
Tue Mar 17 10:18:19 PDT 2009


== Quote from Georg Wrede (georg.wrede at iki.fi)'s article
> The idea of slices and arrays being distinct types does seem to have
> advantages. I've seen a couple of mentions of this lately, but has there
> been a *rigorous* discussion?

No rigorous discussion.  This seems to be one of those thorny issues that noone
wants to delve into seriously.  I had proposed once that T[new], which has been
thrown around here before, be a value type but be implicitly convertible to T[] by
reference.  Here is the proposal reproduced.  Maybe this time it will get some
comments.

Resizable arrays are such an important, heavily used feature that they should get
special treatment from the language, to ensure that they are syntactically
elegant, efficient both at runtime and in terms of compilation time, easy to use,
free of odd corner cases, and in general are true first class citizens.
Nonetheless, D's arrays do have some rough edges.  My proposal would be as follows:

There should be two array types:
T[new] and T[].
This has been proposed before, though not in as much detail as what I'm
suggesting.  The semantics should work as follows:

T[new] is considered a subtype of T[].  This works mostly like you would expect.
T[new] can be implicitly converted to T[].  The twist is that T[] can also be
assigned to T[new] without any explicit conversion, but a copy of the underlying
data is implicitly made for safety.

Assigning either a T[] or a T[new] to a T[] will result in aliasing:

T[] foo;
T[new] bar = new T[N];
bar[0] = 1;
foo = bar;
foo[0] = 2;
writeln(bar[0]);  // Prints 2.

T[new]s are always assigned by value to make concatenation and resizing safe.  The
underlying data is copied implicitly when assigning from a T[] to a T[new] or from
a T[new] to another T[new].

T[new] foo;
// new returns T[new], implicitly converted to T[]
T[] bar = new T[N];
bar[0] = 1;
foo = bar;
foo[0] = 2;
writeln(bar[0]);  // Prints 1.

T[]s can be sliced, but cannot be enlarged or appended to.  They should be laid
out the same way they are now, as a struct of a pointer and a length.

T[new]s can be appended to and enlarged in addition to being sliced.  Their layout
should be a struct of pointer, length, capacity to make appending fast.  This will
also make implicit conversion to T[] essentially free, since all that is necessary
is slicing off the capacity field.

I also wonder if this proposal could be extended to fix some of the covariance
issues with arrays (see Bugzilla 2095).  This might work by only allowing
covariant types to be assigned to T[new], not T[].  For example:

class A{}
class B:A{}

B[new] ba = [new B];
A[] aa = ba;  // Error:  Cannot assign covariant types to T[].
A[new] aa = ba;  // Works, but copy is implicitly made.



More information about the Digitalmars-d mailing list