Annoyance with new integer promotion deprecations

[Rubn]

On Tuesday, 6 February 2018 at 01:07:21 UTC, Meta wrote:
> On Tuesday, 6 February 2018 at 00:18:08 UTC, Jonathan M Davis 
> wrote:
>> On Monday, February 05, 2018 15:27:45 H. S. Teoh via 
>> Digitalmars-d wrote:
>>> On Mon, Feb 05, 2018 at 01:56:33PM -0800, Walter Bright via 
>>> Digitalmars-d
>> wrote:
>>> > 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.
>>
>> +1
>>
>> Occasionally, it's useful, but in most cases, it just causes 
>> bugs - especially when you consider stuff like appending to a 
>> string.
>>
>> - Jonathan M Davis
>
> I remember a fairly old defect, or maybe it was just a post in 
> the Learn forum. Doing "string" ~ 0 would append '\0' to a 
> string, because the int was auto-converted to a char. This 
> still works today:
>
> import std.stdio;
> void main()
> {
>     string msg = "Hello" ~ 0 ~ " D" ~ '\0';
>     writeln(msg);
>     writeln(cast(ubyte[])msg);
>     writeln(cast(ubyte[])"Hello D");
> }

Yah that functionality should be deprecated. Idk how realistic 
that is, there might be a lot of code that relies on the implicit 
conversion, but at the very least the conversion should be 
disabled when it is part of a concat with a string. One of the 
reasons for the "~" operator (iirc) was so remove confusion with 
the "+" operator. This goes backwards to that.

Maybe in the future this could be possible:

static assert("Hello " ~ 10 ~ " world" == "Hello 10 world");

It'd help with CTFE code, I find having to convert integers to 
strings a lot. This is cleaner syntax and don't rely on 
std.conv.to. So it doesn't need to be imported, I'm not sure if 
DMD uses an intrinsic for that as well. I hope it does but can't 
be certain.