On Tue, 24 Mar 2009 20:02:16 -0400, Cristian Vlasceanu
<[email protected]> wrote:
Steven Schveighoffer Wrote:
On Tue, 24 Mar 2009 18:26:16 -0400, Cristian Vlasceanu
<[email protected]> wrote:
> Back to the slices topic: I agree that my proposed "ref" solution
would
> require code changes, but isn't that true for T[new] as well?
>
> Cristian
>
There is not already a meaning for T[new], it is a syntax error. There
is
already a meaning for ref T[].
Yes, but the current, existing meaning will be preserved:
void f(ref T[] a) {
a[13] = 42; // still works as before if "a" is a slice under the hood
a = null; // very easy for the compiler to make this work: a.array =
null
}
OK, I'm not sure I understood your original proposal, before I respond
more, let me make it clear what my understanding was.
In your proposal, a ref T[] a is the same as a slice today. That is,
assignment to a ref T[] simply copies the pointer and length from another
T[] or ref T[]. However, it does not reference another slice struct, but
is a local struct in itself.
In the current situation, a ref T[] is a reference to a slice struct.
That is, assignement to a ref T[] overwrites the pointer and length on the
reference that was passed.
So here is my objection:
void trim(ref char[] c)
{
//
// remove leading and trailing spaces
//
while(c.length > 0 && c[0] == ' ')
c = c[1..$];
while(c.length > 0 && c[$-1] == ' ')
c = c[0..$-1];
}
void foo()
{
char[] x = " trim this! ".dup;
trim(x);
assert(x == "trim this!");
}
Now, in your scheme, the ref simply means that c's data is referencing
something else, not that c is a reference, so the assert will fail, no?
If this isn't the case, let me know how you signify:
1. a normal slice (struct is local, but ptr and length are aliased from
data).
2. a reference of a slice (references an external struct).
-Steve
