const?? When and why? This is ugly!

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Fri, 06 Mar 2009 13:30:22 -0800, Andrei Alexandrescu wrote:
> 
>> Burton Radons wrote:
>>> Andrei Alexandrescu Wrote:
>>>
>>>> Burton Radons wrote:
>>>>> A more accurate way would be for the string type to be "const (char)
>>>>> []", and for functions which retain strings that can't change to take
>>>>> "invariant (char) []". That makes pretty good claims about the nature
>>>>> of the string, but it would clearly result in lots of cast
>>>>> management.
>>>> I use that all the time, it's a great idiom. What cast management
>>>> needs to be done? What I need to do is occasionally insert an .idup on
>>>> the client side because the callee wants a copy. So that's that.
>>>>
>>>>
>>> So long as the object definition of string is "invariant (char) []", I
>>> can't guarantee anything about the nature of the object because you
>>> need to cast to "invariant (char) []" to be able to interface with any
>>> API.
>>>
>>> The good side is that when I changed it to be defined as "const (char)
>>> []" only one line of code made a squeak. That gives me solid actionable
>>> information. If an API is declared as istring, then whatever you give
>>> it must not ever change. If an API is declared as string, then whatever
>>> happens in there, it won't change the data. Pretty good!
>> I have trouble following what you're saying. If what you're saying is
>> essentially that in char[] is a better parameter definition than string
>> for functions that don't need to escape their string argument, then yes,
>> you are entirely right.
>>
>> So what I recommend is:
>>
>> void foo(in char[] s); // foo looks at s, doesn't escape it
>> void bar(string s); // bar needs to save s
>> void baz(char[] s); // baz needs
>> to change s' contents
> 
> I think what Burton is saying is by annointing immutable(char)[] as the 
> type "string," you are essentially sending a message to developers that 
> all strings should be immutable, and all *string parameters* should be 
> declared immutable.  What this does is force developers who want to deal 
> in const or mutable chars have to do lots of duplication or casting, 
> which either makes your code dog slow, or makes your code break const.
> 
> Evidence is how (at least in previous releases) anything in Phobos that 
> took an argument that was a utf8 string of characters used the parameter 
> type "string", making it very difficult to use when you don't have string 
> types.  If you want to find a substring in a string, it makes no sense 
> that you first have to make the argument invariant.  a substring function 
> isn't saving a pointer to that data.
> 
> I think the complaint is simply that string is defined as immutable(char)
> [] and therefore is promoted as *the only* string type to use.  Using 
> other forms (such as in char[] or const(char)[] or char[]) doesn't look 
> like the argument is a string, when the word "string" is already taken to 
> mean something else.
> 
> -Steve

I see. Phobos is being changed to accept in char[] instead of string
wherever applicable. As far as what the default "string" ought to be,
immutable(char)[] is the safest of the three so I think it should be that.

Andrei