Issues with constants, and inout (was Real World usage of D, Today)

kris foo at bar.com
Sat Jan 27 10:04:19 PST 2007


Frits van Bommel wrote:
> kris wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> kris wrote:
>>> [about implicit conversion rules]
>>>
>>>> extern (C) int printf (char*, ...);
>>>>
>>>> class Foo
>>>> {
>>>>         void write (int x) {printf("int\n");}
>>>>         void write (uint x) {printf("uint\n");}
>>>>         void write (long x) {printf("long\n");}
>>>>         void write (char x) {printf("char\n");}
>>>>         void write (wchar x) {printf("wchar\n");}
>>>>         void write (double x) {printf("double\n");}
>>>>
>>>>         void write (char[] x) {printf("char[]\n");}
>>>>         void write (wchar[] x) {printf("wchar[]\n");}
>>>> }
>>>>
>>>> void main()
>>>> {
>>>>         auto foo = new Foo;
>>>>
>>>>         foo.write ('c');
>>>>         foo.write (1);
>>>>         foo.write (1u);
>>>>         foo.write (3.14);
>>>>         //foo.write ("asa");
>>>> }
>>>>
>>>> prints:
>>>>
>>>> char
>>>> int
>>>> uint
>>>> double
> 
> [snip]
> 
>>>> Now for the broken part. When you uncomment the string constant, the 
>>>> compiler gets all confused about whether it's a char[] or wchar[]. 
>>>> There is no defaulting to one type, as there is for other constants 
>>>> (such as char). It /is/ possible to decorate the string constant in 
>>>> a similar manner to decorating integer constants:
>>>>
>>>> foo.write ("qwe"c);
>>>>
>>>> And this, of course, compiles. It's a PITA though, and differs from 
>>>> the rules for other constants.
>>>
>>>
>>> I talked to Walter about this and it's not a bug, it's a feature :o). 
>>> Basically it's hard to decide what to do with an unadorned string 
>>> when both wchar[] and char[] would want to "attract" it. I understand 
>>> you're leaning towards defaulting to char[]? Then probably others 
>>> will be unhappy.
>>
>>
>> You'll have noticed that the constant 'c' defaults to /char/, and that 
>> there's no compile-time conflict between the write(char) & 
>> write(wchar)?  Are people unhappy about that too? Perhaps defaulting 
>> of char constants and int constants should be abolished also?
> 
> 
> It's a bit more complicated with character literals than just defaulting 
> to 'char':
> -----
> import std.stdio;
> void main() {
>     writefln(typeid(typeof('a')));          // c <= \u007f
>     writefln(typeid(typeof('\uabcd')));     // c <= \uffff
>     writefln(typeid(typeof('\U000abcde'))); // c <= \U0010ffff
> 
> }
> -----
> outputs:
> """
> char
> wchar
> dchar
> """
> So it defaults to the *smallest* character type that can hold it in one 
> element.
> Pretty cool, actually.
> 
> This also applies to other types, by the way. If you type an integer 
> literal that won't fit into an 'int', it'll be a 'long' constant 
> (assuming it fits), not an 'int' constant.

Yes. Kinda glossed over that part, didn't I <g>


> Perhaps we should do something similar with string literals, defaulting 
> it to use an array of the smallest character type that can hold all of 
> the characters in the string (i.e. the maximum "character type" of the 
> component characters) ?
> That seems like a reasonable rule. And it has the added benefit that 
> "some string constant".length will always be the number of characters in 
> the string.


Yes, that would seem eminently reasonable.



More information about the Digitalmars-d mailing list