Strange implicit conversion integers on concatenation

[12345swordy]

On Monday, 5 November 2018 at 23:00:23 UTC, Jonathan M Davis 
wrote:

> Regardless, if you attempt to add keywords to the language at 
> this point, you will almost certainly lose. I would be _very_ 
> surprised to see Walter or Andrei go for it.
What exactly makes you say that? I had scan read the old dips 
that were rejected on the wiki and on the github, and it seems to 
be rejected for other reasons.
Is there previous discussion that you(or others) can linked to?

> Whether you think attributes are easy to read or not, they 
> don't eat up an identifier, and Walter and Andrei consider that 
> to be very important.
The feature that I have in mind requires to be an keyword as it 
heavily inspired by C# explicit and implicit keywords.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/explicit
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/implicit
Even c++ have type conversions.
http://www.cplusplus.com/doc/tutorial/typecasting/

Bear in mind though that I am still in the brainstorm session and 
research process in regarding this. Don't expect the details from 
me, as I havn't figure everything out yet.
> AFAIK, they also don't consider attributes to be a readability 
> problem. So, even if trying to add some sort of implicit or 
> explicit marker to parameters made sense (and I really don't 
> think that it does), I think that Walter and Andrei have made 
> it pretty clear that that sort of thing would have to be an 
> attribute and not a keyword.
I don't want the implicit and explicit keywords to be attributes 
in the dip I going to write, unless I really have to in order to 
get the DIP approval from Walter and Andrei.

> And honestly, I think that any DIP trying to add general 
> control over implicit and explict conversions in the language 
> has a _way_ lower chance of being accepted than one that gets 
> rid of implicit conversions between character types and integer 
> types. However, in the end, one does not depend on the other or 
> even really have much to do with the other. A DIP to fix the 
> implicit conversions between character types and integer types 
> would be a DIP to fix precisely that, whereas a DIP to mark 
> parameters with implicit or explicit would be about trying to 
> control implicit or explicit conversions in general and not 
> about character or integer types specifically, so while they 
> might be tangentially related, they're really separate issues.

That is very good point. Well consider that when writing the dip.

> Given the recent DIP on copy constructors and the discussion 
> there, it would not surprise me to see a future DIP about 
> adding @implicit to constructors to allow for implicit 
> construction, though I don't know how likely it is for such a 
> DIP to be accepted given that D's approach (outside of built-in 
> types anyway) has generally been to avoid implicit conversions 
> to reduce the risk of bugs, and when combined with alias this, 
> things really start to get interesting.
Gah, don't remind me of alias this. That can of worms has yet to 
be open with multi alias this. Which btw is STILL not implemented 
yet! Hell, I will sign up for the next round of community fund 
projects just to implement the damn thing, because I am that 
impatient.

> But I would think that the chances of that getting accepted are 
> far greater than adding attributes to parameters (be they 
> keywords or actual attributes). Regardless, that's an issue of 
> conversions in general, and not just implicit conversions 
> between character types and integer types, which is really what 
> the discussion is about fixing here, and that can be fixed 
> regardless of what happens with providing additional control 
> over implicit conversions in general.
>
> - Jonathan M Davis

Sure thing, though the DIP process for deprecation of small 
features shouldn't be that slow!

-Alex