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