On Tue, 20 Oct 2009 14:43:16 -0400, Bill Baxter <wbax...@gmail.com> wrote:
On Tue, Oct 20, 2009 at 11:30 AM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
If your goal is to affect the original array, then you should accept a
ref
argument or not append to it.
I think that's an entirely reasonable (and easy to explain) stance.
I've definitely spent time tracking down exactly such bugs, where I
meant to make the argument a ref but didn't. If the above is to be
the official stance, then I think it should be enforced by the
compiler. Appending to non-ref slice args should be an error.
Except when you are passing ownership of an array. Basically, there are
four modes:
T[] x : a) you are passing ownership to the function, and the array might
not be deterministically usable after the function returns, e.g. T[]
padAndCapitalize(T[]). Usually such functions' return values are
deterministic, and the focus of what you care about.
-or-
b) you are lending ownership to the function, only the array
elements will be altered, e.g. replace().
ref T[] x : You are lending ownership of the array to the function, but
you get ownership back, e.g. push(). Fully deterministic altering.
const(T)[] x : You retain ownership of the array, the function cannot
alter it, e.g. toUpper().
So it's not possible to flag on the signature between the first a) and b)
modes, we must currently rely on documentation. But the "append and
modify" routines are pretty rare.
Essentially, what you want is a type where the length is const, but the
data is mutable. I think creating such a type should be possible in the
library.
But fixing the append problem alone is a huge step forward, since all of
these cases could result in corruption of totally unrelated data if the
arrays were appended to. Especially the const version is bad.
-Steve
