On Monday, 12 November 2018 at 20:23:42 UTC, Andrei Alexandrescu wrote:
> 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.

I'd call that a good thing, many people are surprised when ~ x doesn't do ~ to!string(x), and besides, a number isn't really a character.

I'd be happy if you had to write:

`Number value: ` ~ char(65).

On Monday, 12 November 2018 at 20:23:42 UTC, Andrei Alexandrescu 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.
>
>
> Andrei

We could replace the

string res = `Number value: ` ~ 65;

with:

string res = `Number value: ` ~65.ToString();

which makes

string res = `Number value: 65`

Via extension methods with compile time reflection. (Which I am very exited to see with your upcoming DIP that overhauls the compile time reflection!)

Which display the intent of converting 65 to a literal string equivalent.

Alex

On Monday, 12 November 2018 at 20:23:42 UTC, Andrei Alexandrescu wrote:

> 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.
>
>
> Andrei

I sure hope that happens. As I wrote above, this bit me when I started using the language, and it didn't leave a good impression.

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

On 11/12/18 3:23 PM, Andrei Alexandrescu 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.
>>
> 
> 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.

I'm wondering if you realized what you are saying there. Like "if we deprecate one crappy behavior, we have to deprecate all the crappy behavior"

Yes, please.

-Steve