.NET on a string

[Steven Schveighoffer]

On Tue, 24 Mar 2009 20:02:16 -0400, Cristian Vlasceanu  
<cristian at zerobugs.org> wrote:

> Steven Schveighoffer Wrote:
>
>> On Tue, 24 Mar 2009 18:26:16 -0400, Cristian Vlasceanu
>> <cristian at zerobugs.org> 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