Why are unsigned to signed conversions implicit and don't emit a warning?

[Andrew Wiley]

On Sun, Apr 10, 2011 at 7:57 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> Andrej Mitrovic:
>> > I just had a little bug in my code. In the WindowsAPI, there's this
>> > alias:
>> >
>> > alias ubyte BYTE;
>> >
>> > Unfortunately I didn't check for this, and I erroneously assumed BYTE was
>> > a signed value (blame it on my lack of coffee).
>>
>> I and Don have asked (in Bugzilla and elsewhere) to change the built-in
>> names into sbyte and ubyte, to avoid the common confusions between signed
>> and unsigned bytes in D, but Walter was deaf to this.
>>
>> > But what really surprises me is that these unsigned to signed conversions
>> > happen implicitly. I didn't even get a warning, even though I have all
>> > warning switches turned on.
>>
>> Add your vote here (I have voted this), a bug report from 07 2006, but
>> Walter doesn't like this warning, and warnings in general too:
>> http://d.puremagic.com/issues/show_bug.cgi?id=259
>
> Personally, I see _zero_ value in renaming byte, int, etc. to sbyte, sint,
> etc. It's well-known that they're signed. I don't see how adding an extra s
> would make that any clearer. Their names are perfectly clear as they are.
>
> However, I also would have thought that converting between signed and unsigned
> values would be just as much of an error as narrowing conversions are - such
> as assigning an int to a byte. And arguably, assigning either an unsigned
> value to a signed value or vice versa is _also_ a narrowing conversion. So, I
> would have thought that it would be an error. Apparently not though.

I agree completely. The names are fine, we just need to get the
conversions right.
Yes, they aren't "theoretically correct" but integers as we define
them aren't even integers in the mathematical sense, so the whole
system isn't "theoretically correct." D's scheme, while not "pure," is
very natural to use.