Re: Annoyance with new integer promotion deprecations

[Rubn via Digitalmars-d]

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.