To Walter, about char[] initialization by FF
Unknown W. Brackets
unknown at simplemachines.org
Wed Aug 2 00:31:31 PDT 2006
I fail to understand why I want another ambiguous type in my
programming. I am glad that when I type "int", I know I have a number
and not a pointer.
I am glad that when I type char, I again know what I have. No
guesswork. Your proposals sound like shooting myself in the foot.
No fun. I'll take that helmet you offered first.
-[Unknown]
> "Unknown W. Brackets" <unknown at simplemachines.org> wrote in message
> news:eapdsg$qeo$1 at digitaldaemon.com...
>> I'm trying to understand why this 0 thing is such an issue. If your
>> second statement is valid, it makes the first moot - 0 or no 0. Why does
>> it matter, then?
>
> Declaration of char.init == 0 pretty much means that
> D has no strict requirement that char[] shall contain only UTF-8
> encoded sequences but any other encodings suitable for
> the application.
>
> char.init == 0 will resolve situation we see in Phobos now.
> char[] de facto is used for other than utf-8 encodings.
>
> char.init == 0 tells everybody that char can also be used
> for representing unicode *code points* with asuumption
> that offset value (mapping on full Unicode set, aka codepage) is stored
> somewhere in application or well known to it.
>
> char.init == 0 also highlights the fact that it is safe to
> use char[] as C string processing functions and passing them to non D
> modules and libraries.
> Is it UTF-8 encoded or not - does not matter - type is universal enough.
>
> Andrew.
>
>
>
>
>
>
>
>> -[Unknown]
>>
>>
>>> Another option will be to change char.init to 0 and forget about the
>>> problem
>>> left it as it is now. Some good string implementation will
>>> contain encoding field in string instance if needed.
>>>
>>> Andrew.
>>>
>>>
>
More information about the Digitalmars-d
mailing list