string types: const(char)[] and cstring

Aarti_pl aarti at interia.pl
Tue May 29 00:58:16 PDT 2007


Bill Baxter pisze:
> Oskar Linde wrote:
>> Myron Alexander skrev:
>>> noSpam wrote:
>>>> Walter Bright wrote:
>>>>> Derek Parnell wrote:
>>>>>>  const(char)[]  // A mutable array of immutable characters?
>>>>>>  const(char[])  // An immutable array of mutable characters?
>>>>>>  const(const(char)[]) // An immutable array of immutable characters?
>>>>>>  char[]         // A mutable array of mutable characters?
>>>>>>
>>>>>> What will happen with the .reverse and .sort array properties when 
>>>>>> used
>>>>>> with const, invariant, and final qualifiers?
>>>>>
>>>>> They'll all fail.
>>>>
>>>> I think it's better to return reversed/sorted copy. This will make 
>>>> such change more backward compatibile.
>>>
>>> This makes sense. For immutable arrays, the definition should drop 
>>> "in place" and just return a copy.
>>
>> Which would be very confusing. This is instead a perfect opportunity 
>> to  take the *much* better path of finally depreciating the .sort and 
>> .reverse "properties". Equally good or better library implementations 
>> are possible (and exists). For example, .sort can't take an ordering 
>> predicate. 
> 
> +1 (and thanks for your predicate-accepting sort routine, Oskar!)

+1

> 
>> Also, the special casing of reversing char[] and wchar[] arrays, 
>> preserving the encoded unicode code points is definitely (imho) too 
>> specialized to belong in the language (runtime) as opposed to a library.
> 
> No opinion there.  What about the special code-point-at-a-time foreach 
> for char[]?  Do you dislike that too?
> 

IMHO that should not be in language. That's why I am opting for string 
*library* class/struct which could take care about such cases.

BR
Marcin Kuszczak
(Aarti_pl)



More information about the Digitalmars-d-announce mailing list