Reading about D: few questions
Jonathan M Davis
jmdavisProg at gmx.com
Fri Dec 23 15:16:25 PST 2011
On Friday, December 23, 2011 09:47:35 Ali Çehreli wrote:
> - To be more useful, function parameters should not insist on immutable
> data, yet we type string all over the place.
That depends. If they're going to have to idup the data anyway, then it's
better to require that the argument be immutable so that that cost is clear.
The worst is taking const and then iduping, because then you're forced to idup
strings which didn't need to be iduped.
And in general, operating on strings is more efficient than mutable character
arrays, because you can slice them with impunity, whereas you often have to
dup or idup mutable arrays in order to avoid altering the original data. The
area where the immutability becomes problematic is when you actually want to
directly mutate a string - but that's generally a rather iffy thing to do with
UTF-8 anyway, since you have to deal with the varying length of the various
code points within the string.
That being said, an increasing number of functions in Phobos are templated on
string type so that you can use whatever string type that you want with them.
And there is a push (at least with toString) to add the ability to put the
result of a string function into an existing string of some variety (be it
using a delegate or an output range). So, you'll be forced to use string less,
but the reality of the matter is that in the general case you should probably
be using string anyway (there are, of course, always exceptions).
> - To be more useful, functions should not insist on the mutability of
> the data that they return.
> The following function makes a new string:
> char endWithDot(const(char) s)
> return s ~ '.';
> char s;
> s ~= "hello";
> auto a = endWithDot(s);
> It is good that the parameter is const(char) so that I could pass the
> mutable s to it.
> But the orthogonal problem of the type of the return is troubling. The
> result is clearly mutable yet it can't be returned as such:
> Error: cannot implicitly convert expression (s ~ '.') of type
> const(char) to char
> We've talked about this before. There is nothing in the language that
> makes me say "the returned object is unique; you can cast it to mutable
> or immutable freely."
In general, D doesn't have features where the programmer says that something
is okay. It's too interested in making guarantees for that. Either it can
guarantee something, or you force it with a cast. I can't think of even one
feature where you say that _you_ guarantee that something is okay. Casting is
your only option.
That being said, the language is improving in what it can guarantee and in
what it can do thanks to those guarantees. For instance, if you have a pure
function and the compiler can guarantee that the return value doesn't
reference anything in the argumetns passed in, then the return value is
implicitly convertible to whatever const-ness you want.
If you want to be making such guarantees yourself, then what you typically
have to do is templatize the function and take advantage of static if and D's
compile-time reflection capabilities. Phobos does this quite a bit to improve
performance and avoid having to duplicate data.
Your particular example is quite easily fixed though. The issue is that the
string which was passed in is typed as const(char), and the expression s ~
'.' naturally results in the same type. But it's quite clear that the
resulting string could be of any constness, since it's a new string. So, just
tell it what constness to have by casting it.
- Jonathan M Davis
More information about the Digitalmars-d-learn