On May 17, 11 12:04, Don wrote:
> Nick Sabalausky wrote:
>> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
>> news:op.vvk48tn9eav7ka@localhost.localdomain...
>> (int/short/byte can sometimes implicitly cast to dchar/wchar/char)
>>> What do you think?
>>>
>>
>> Ick! Kill it!
>>
>>
>
> It's not easy. Simply disallowing it would make code like this illegal:
>
> char c = '0' + n;
>
>

It is already illegal. You cannot implicitly convert an 'int' to 'char' (Error: cannot implicitly convert expression (48 + n) of type int to char).

On 5/16/2011 9:09 PM, Jonathan M Davis wrote:
> On 2011-05-16 21:04, Don wrote:
>> It's not easy. Simply disallowing it would make code like this illegal:
>>
>> char c = '0' + n;
>
> Well, forcing the n to be cast to char or byte would do it, but that _is_ kind
> of ugly.
>
> char c = '0' + cast(char)n;
>
> Definitely a good point though.

It's THE reason why such casts are not allowed. Pascal requires such casts, and I always hated it for that.

The casts are not only annoying, they can cause bugs when the types of the rest of the expression are changed in maintenance.

There isn't any simple answer to mixed integer type arithmetic, although there are many "obvious" answers that have subtly pernicious behavior.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:iqsu2b$1aqs$1@digitalmars.com...
> On 5/16/2011 9:09 PM, Jonathan M Davis wrote:
>> On 2011-05-16 21:04, Don wrote:
>>> It's not easy. Simply disallowing it would make code like this illegal:
>>>
>>> char c = '0' + n;
>>
>> Well, forcing the n to be cast to char or byte would do it, but that _is_
>> kind
>> of ugly.
>>
>> char c = '0' + cast(char)n;
>>
>> Definitely a good point though.
>
> It's THE reason why such casts are not allowed. Pascal requires such casts, and I always hated it for that.
>
> The casts are not only annoying, they can cause bugs when the types of the rest of the expression are changed in maintenance.
>
> There isn't any simple answer to mixed integer type arithmetic, although there are many "obvious" answers that have subtly pernicious behavior.
>

I was going to suggest the rule:

"char + numeric type == char" (and likewise for wchar/dchar), provided that the value range propogation works out, and if it doesn't then you do: char c = cast(char)('0' + n)

Is that one of the "obvious" answers that has subtly pernicious behavior? If so, I'm curious what the problem with it is.

On Tue, 17 May 2011 00:04:07 -0400, Don <nospam@nospam.com> wrote:

> Nick Sabalausky wrote:
>> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vvk48tn9eav7ka@localhost.localdomain...
>> (int/short/byte can sometimes implicitly cast to dchar/wchar/char)
>>> What do you think?
>>>
>>  Ick! Kill it!
>>
>
> It's not easy. Simply disallowing it would make code like this illegal:
>
> char c = '0' + n;
>
>

don't you mean dchar c = '0' + n?

And I wouldn't mind if dchar + int => dchar.  I also wouldn't mind requiring a cast when range propagation proves the dchar could be invalid.

In any case, I think:

string s = "hello";
s ~= 123;

looks like it should result in:

assert(s == "hello123");

Especially anyone coming from any other language.  They certainly would not expect it to be "hello{"

To me, dchar is the more specialized type, it's like a typedef of uint -- you should be able to implicitly cast to uint/int, but not to dchar.

It's kind of like a pointer, you can do this:
int n;
int* ptr;
ptr += n;

but you can't do this:

ptr = n;

-Steve