.NET on a string

[Cristian Vlasceanu]

At a first look yes I think the assertion will fail, but not if you declare 
x:
ref char[] x = "   trim this!   ".dup;

It could be possible to tweak the compiler so that it forces you to declare 
x like that

"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in umessage 
news:op.urex03gyeav7ka at steves.networkengines.com...
> 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