Annoyance with new integer promotion deprecations

[H. S. Teoh]

On Mon, Feb 05, 2018 at 01:56:33PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/5/2018 12:45 PM, H. S. Teoh wrote:
> > Sticking to C promotion rules is one of the scourges that continue to
> > plague D;
> 
> It's necessary. Working C expressions cannot be converted to D while
> introducing subtle changes in behavior.

Exactly; maintaining compatibility with C, the ruiner of all good
things, is a scourge to D that prevents D from adopting saner rules.


> > another example is char -> byte confusion no thanks to C traditions:
> > 
> > 	int f(dchar ch) { return 1; }
> > 	int f(byte i) { return 2; }
> > 	void main() {
> > 		pragma(msg, f('a'));
> > 		pragma(msg, f(1));
> > 	}
> > 
> > Exercise for reader: guess compiler output.
> 
> 'a' and 1 do not match dchar or byte exactly, and require implicit
> conversions. D doesn't have the C++ notion of "better" implicit
> conversions for function arguments, instead it uses the
> "leastAsSpecialized" C++ notion used for template matching, which is
> better.
> 
> The idea is a byte can be implicitly converted to a dchar, [...]

This is the root of the problem.  Character types should never have been
implicitly convertible to/from arithmetic integral types in the first
place.

Again, compatibility with C pessimizes D semantics.  Since D
deliberately defines byte/ubyte as different from char, and char is
defined explicitly to be a UTF-8 code unit, there is really no good
reason to allow implicit conversions between them.  That just undermines
the raison d'être for having separate ubyte and char types, and is a
stink we inherited from C that really ought to be shed already.

It should be C code ported to D that is forced to use casts to explicate
intent, rather than forcing D code to jump through cast hoops just so we
remain "compatible" with C.


T

-- 
Why did the mathematician reinvent the square wheel?  Because he wanted to drive smoothly over an inverted catenary road.