On Sat, Apr 29, 2017 at 11:24:36AM +0000, Patrick Schluter via Digitalmars-d-announce wrote:
> On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote:
> > The latest WAT I found in D is this one, see if you can figure it out:
> > 
> > 	char ch;
> > 	wchar wch;
> > 	dchar dch;
> > 
> > 	pragma(msg, typeof(true ? ch : ch));	// char - OK
> > 	pragma(msg, typeof(true ? ch : wch));	// int - WAT?
> > 	pragma(msg, typeof(true ? wch : wch));	// wchar - OK
> > 	pragma(msg, typeof(true ? wch : dch));	// uint - WAT?
> > 	pragma(msg, typeof(true ? dch : dch));	// dchar - OK
> > 
> > How an alternation between two character types ends up being int is beyond me, but even more inscrutible is why ch : wch produces int but wch : dch produces uint.
> 
> That's the C integer promotion rule, nothing suprising here.
> 
> C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int."
> 
> While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing.  Maybe the documentation should cite more prominently from the C standard on that point. While it is quite obvious, I noticed that a lot of people do not know how it works.

The problem is that while C integer promotion works well for C, it doesn't for D so much. Perhaps it worked well in the beginning days of D, when D was much closer to C, but today's D has significantly diverged from C in many respects, including making a clear(?) distinction between character types vs. integer types (e.g., char != ubyte). There has been a regression (at least) caused by the above adherence to C integer promotion rules:

	https://issues.dlang.org/show_bug.cgi?id=17358

There has also been bugs / problems related to overloading between int and char types of the same width (the wrong overload gets chosen).

The problem is that because D makes it a point that char and ubyte are different (ditto for wchar / ushort, dchar / uint), people have come to expect that they should be consistently treated differently. But then we run into anachronisms like C integer promotion rules that basically disregard the distinction between integer and character types. So now you have this schizophrenic situation where part of the language (a good chunk of Phobos, for example, and some parts of the compiler/language -- e.g., char.init != ubyte.init) considers them as two different things, but other parts of the language (e.g. here) disregard their distinction.

That this inconsistency should lead to bugs should be no surprise.  The question now is, are we going to *fix* this situation at its root, or are we going to merely patch over it half-heartedly in the name of not OMG potentially breaking wrong codez! -- and thereby perpetuate this bug-prone situation? I sure hope it's not the latter.


T

-- 
The richest man is not he who has the most, but he who needs the least.

On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter wrote:
> For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against.

The C model isn't much like x86 at all. You can do operations on 8 bit and 16 bit registers on x86, but C doesn't reflect that reality.

I usually defend D's behavior of "blame C". Compatibility is useful for us and conservative programmers like familiarity, but I can't defend C's rules on the merits. They aren't like the processor and they aren't even that useful.