DMD 2.000 alpha release

[Charles D Hixson]

Walter Bright wrote:
> Johan Granberg wrote:
>> I don't think invariant here is such a great idea, consider the following
>> function.
>>
>> void foo(string s){}
>>
>> if string is const this can be called with both char[] and 
>> const(char)[] (if
>> not please correct me) but if my understanding is correct char[] would 
>> not
>> work if string is invariant. This will lead to an unessesary amount of
>> cast(invariant) when calling functions on local strings (as functions 
>> that
>> create strings will have to modify the when they are being built).
> 
> That's essentially my argument against it, too. The other side is that 
> treating strings as if they are value types is common and effective in 
> other languages. (For example, strings in Perl are invariant.)
> 
> One of the reasons for adding .idup is to reduce the need to cast to 
> invariant.

I realize that string is, at it's base, an alias.  But 
thinking of string as a type, if string is a const, then there 
ought to be a word to allow the declaration of non-const strings.

I.e., if a type that is not inherently const is made const by 
the language, then there ought to be a modifier to remove the 
const'ness of it.  This is clumsy, so perhaps strings should 
not be const.

As for the way that other languages do things... I seem to 
recall that the justification for implementing const strings 
has usually been speed.  Would that apply in the case of D?

So my argument against const strings is basically shaped 
around symmetry.  If symmetry is broken by having strings be 
const, then to restore it one would need a type modifier 
meaning mutable

The potential argument in favor of const strings seems, to me, 
to be speed.  But I don't know whether it applies.