Reading about D: few questions

[Jonathan M Davis]

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