[Design] return char[] or string?
Stewart Gordon
smjg_1998 at yahoo.com
Sun Jul 29 13:54:48 PDT 2007
While I haven't got into using D 2.x, I've already begun thinking about
making libraries compatible with it. On this basis, a design decision to
consider is whether functions that return a string should return it as a
char[] or a const(char)[]. (I use "string" with its general meaning, and
"const(char)[]" to refer to that specific type. Obviously for 1.0
compatibility, I'd have to use the "string" alias wherever I want
const(char)[].)
Obviously, a function that takes a string as a parameter has to take in a
const(char)[], to be able to accept a string literal or otherwise a constant
string. But what about the return type?
Looking through the 2.x version of std.string, they all return const(char)[]
rather than char[]. (Except for those that return something else such as a
number.) This is necessary in most cases because of the copy-on-write
policy.
But otherwise, it seems that both have their pros and cons.
There seem to be two cases to consider: libraries targeted specifically at D
2.x, and libraries that (attempt to) support both 1.x and 2.x. At the
moment, it's the latter that really matters.
Let's see. The string-returning functions in my library more or less fall
into these categories:
(a) functions that build a string in a local variable, which is then
returned
(b) functions that return a copy of a member variable
(c) property setters and the like that simply pass the argument through
(d) functions that call a function in Phobos and return the result
In the case of (a), there is no obvious benefit to returning a const(char)[]
rather than a char[].
Many of the cases of (b) are property getters. If we have such things
returning a const(char)[], then the getter no longer needs to copy the
member variable. Though versioning would be needed to implement this
behaviour without causing havoc under 1.x. The alternative, leaving them
returning char[], leads to inconsistency with (c), which would have to
return const(char)[].
That leaves (d), to which the obvious answer is to return whatever type the
Phobos function returns.
On one hand, if the string is generated on the fly, and so altering it would
not cause a problem, it seems wasteful to return a const(char)[] only for
the caller to have to .dup it if it wants to modify it.
On the other hand, from the library user's point of view, it can be seen as
a confusing inconsistency if some functions return char[] and others
const(char)[], when no difference in the semantics of what's returned
accounts for this. It also borders on breaking the encapsulation principle,
whereby internal implementation details should not be exposed in my
library's API.
What do you people think?
Stewart.
More information about the Digitalmars-d-learn
mailing list