string is rarely useful as a function argument

[deadalnix]

Le 28/12/2011 21:43, Jonathan M Davis a écrit :
> On Wednesday, December 28, 2011 10:27:15 Andrei Alexandrescu wrote:
>> I'm afraid you're wrong here. The current setup is very good, and much
>> better than one in which "string" would be an alias for const(char)[].
>>
>> The problem is escaping. A function that transitorily operates on a
>> string indeed does not care about the origin of the string, but storing
>> a string inside an object is a completely different deal. The setup
>>
>> class Query
>> {
>>       string name;
>>       ...
>> }
>>
>> is safe, minimizes data copying, and never causes surprises to anyone
>> ("I set the name of my query and a little later it's all messed up!").
>>
>> So immutable(char)[] is the best choice for a correct string abstraction
>> compared against both char[] and const(char)[]. In fact it's in a way
>> good that const(char)[] takes longer to type, because it also carries
>> larger liabilities.
>>
>> If you want to create a string out of a char[] or const(char)[], use
>> std.conv.to or the unsafe assumeUnique.
>
> Agreed. And for a number of functions, taking const(char)[] would be worse,
> because they would have to dup or idup the string, whereas with
> immutable(char)[], they can safely slice it without worrying about its value
> changing.
>

Is inout a solution for the standard lib here ?

The user could idup if a string is needed from a const/mutable char[]