Sergey Gromov wrote:
Sat, 07 Mar 2009 15:19:50 -0800, Andrei Alexandrescu wrote:
To recap, if an API takes a string and all you have a char[], DO NOT
CAST IT. Call .idup - better safe than sorry. The API may evolve and
store a reference for later. Case in point: the up-and-coming
std.stdio.File constructor initially was:
this(in char[] filename);
Later on I decided to save the filename for error message reporting and
the such. Now I had two choices:
(1) Leave the signature unchanged and issue an idup:
this.filename = to!string(filename); // issues an idup
(2) Change the signature to
this(string filename);
Now all client code that DID pass a string in the first place (the vast
majority) was safe _and_ efficient. The minority of client code was that
that had a char[] or a const(char)[] at hand. That code did not compile,
so it had to insert a to!string on the caller side.
As has been copiously shown in other languages, the need for
character-level mutable string is rather rare. So most of the time you
will not traffic in char[], but instead you'll have a immutable(char)[]
to start with. This further erodes the legitimacy of your concern.
My file names are constructed most of the time. And most of the time
they are simple char[]s.
Ehm. Mine are also constructed, but somehow come in string format, e.g.:
string basename;
...
auto f = File(basename ~ ".txt");
It is not obvious that File should store the file name. It's not
strictly necessary. It's an *implementation detail.* Now you expose
this implementation detail through the class interface, and you do this
without any good reason. You save a 150 byte allocation per file.
Nice.
It's just an example, the point being that there things are always fast
and safe. In many cases there's much more at stake and you can't rely on
idioms that allocate memory needlessly.
I can understand when a hash takes an immutable key. It's in the hash's
contract. Various lazy functions could take immutable input to
guarantee correct lazy execution. But I think that overall use of
immutable types should be rare and thoroughly thought-out. They should
be used only when it's absolutely, provably necessary. That's why I
think aliasing string as immutable is a mistake. It felt wrong when I
discovered D a year ago, and it feels wrong now.
That may be because you are writing C in D. Immutable strings should
allow solid coding without much friction.
Andrei