Strange implicit conversion integers on concatenation

[H. S. Teoh]

On Mon, Nov 05, 2018 at 03:58:40PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Monday, 5 November 2018 at 15:36:31 UTC, uranuz wrote:
> > I believe that following code shouldn't even compile, but it does
> > and gives non-printable symbol appended at the end of string.
> 
> Me too, this is a design flaw in the language. Following C's example,
> int and char can convert to/from each other. So string ~ int will
> convert int to char (as in reinterpret cast) and append that.
> 
> It is just the way it is, alas.

I have said before, and will continue to say, that I think implicit
conversion between char and non-char types in D does not make sense.

In C, converting between char and int is very common because of the
conflation of char with byte, but in D we have explicit types for byte
and ubyte, which should take care of any of those kinds of use cases,
and char is explicitly defined to be a UTF8 code unit.  Now sure, there
are cases where you want to get at the numerical value of a char --
that's what cast(int) and cast(char) is for.  But *implicitly*
converting between char and int, especially when we went through the
trouble of defining a separate type for char that stands apart from
byte/ubyte, does not make any sense to me.

This problem is especially annoying with function overloads that take
char vs. byte: because of implicit conversion, often the wrong overload
ends up getting called WITHOUT ANY WARNING.  Once, while refactoring
some code, I changed a representation of an object from char to a byte
ID, but in order to do the refactoring piecemeal, I needed to overload
between byte and char so that older code will continue to compile while
the refactoring is still in progress.  Bad idea.  All sorts of random
problems and runtime crashes happened because C's stupid int conversion
rules were liberally applied to D types, causing a gigantic mess where
you never know which overload will get called. (Well OK, it's
predictable if you sit down and work it out, but it's just plain
annoying when a lousy char literal calls the byte overload whereas a
char variable calls the char overload.)  I ended up having to wrap the
type in a struct just to stop the implicit conversion from tripping me
up.


T

-- 
Some days you win; most days you lose.