Strange implicit conversion integers on concatenation

[Jonathan M Davis]

On Monday, November 12, 2018 1:23:42 PM MST Andrei Alexandrescu via 
Digitalmars-d wrote:
> On 11/12/18 3:01 PM, 12345swordy wrote:
> > On Monday, 5 November 2018 at 15:36:31 UTC, uranuz wrote:
> >> Hello to everyone! By mistake I typed some code like the following
> >> without using [std.conv: to] and get strange result. I believe that
> >> following code shouldn't even compile, but it does and gives
> >> non-printable symbol appended at the end of string.
> >> The same problem is encountered even without [enum]. Just using plain
> >> integer value gives the same. Is it a bug or someone realy could rely
> >> on this behaviour?
> >>
> >> import std.stdio;
> >>
> >> enum TestEnum: ulong {
> >>    Item1 = 2,
> >>    Item3 = 5
> >> }
> >>
> >> void main()
> >> {
> >>     string res = `Number value: ` ~ TestEnum.Item1;
> >>     writeln(res);
> >> }
> >>
> >> Output:
> >> Number value: 
> >
> > Welp with the recent rejection of the DIP 1005, I don't see this being
> > deprecated any time soon.
> >
> > -Alex
>
> If we deprecate that we also need to deprecate:
>
>      string res = `Number value: ` ~ 65;
>
> Not saying we shouldn't, just that there are many implications.

And honestly, that's _exactly_ the sort of expression that we'd be looking
to have deprecated, because it usually causes bugs. And it just gets worse
in more complex expressions (ones involving the ternary operator seem to be
particularly popular from what I recall). D specifically made character
types separate from integer types, because character types have a distinct
meaning separate from integer types, and then it shot itself in the foot by
allowing them to more or less freely mix via implicit conversions. The main
saving grace is the fact that most code uses char, and the arithmetic
expressions result in int, so to assign back, you need to cast because it's
a narrowing conversion. So, a lot of the casts that we'd want to be required
when converting between integer types and character types are fortunately
required anyway, but stuff like ~ gets around it in many cases, and if
you're using dchar, you're not protected by narrowing conversions. So, the
problem still exists, and it still causes bugs.

Many of us see the fact that code like

    string res = `Number value: ` ~ 65;

compiles as wholly negative, though based on what Walter has said in the
past, unless something has changed, I'm sure that he does not agree on that
count, and the fact that this DIP on bool was rejected on the grounds that
you guys think that bool should be treated as an integer type does make it
sound like it's going to be difficult to convince you that the character
types shouldn't be treated as integer types.

- Jonathan M Davis