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" <[email protected]> wrote in umessage news:[email protected]... > 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
