Strange implicit conversion integers on concatenation

[Jonathan M Davis]

On Monday, November 5, 2018 7:47:42 PM MST 12345swordy via Digitalmars-d 
wrote:
> 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?

I would have to go digging through the newsgroup history. It's come up on a
number of occasions in various threads, and I couldn't say which at this
point. But the very reason that we started putting @ on things in the first
place was to avoid creating keywords. We did it before user-defined
attributes were even a thing. And for years now, any time that it's been
considered to add any kind of attribute, it always starts with @. It has
been years since anything involving adding a new keyword gotten anywhere.
Similiarly, Walter has shot down the idea of using contextual keywords
(which you can probably find discussions on pretty easily by searching the
newsgroup history).

So, if you want to create a DIP that proposes adding implicit and explicit
as keywords, feel free to do so, but from what I know of Walter and Andrei's
position on the topic of keywords from what they've said in the newsgroup or
in anything they've said in any discussions that I've had with them in
person, they're not going to be interested in adding new keywords when
adding an attribute that starts with @ will work, because adding keywords
means restricting the list of available identifiers, whereas adding new
attributes does not. I honestly do not expect that D2 will _ever_ get any
additional keywords and would be very surprised if it ever did.

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

I won't claim the the DIP process couldn't or shouldn't be improved, but at
least we now have a DIP process that actually works, even if it can be slow.
With the old process, DIPs basically almost never went anywhere. A few did,
but most weren't ever even seriously reviewed by Walter and Andrei. While it
may not be perfect, the current process is an _enormous_ improvement.

- Jonathan M Davis