Strange implicit conversion integers on concatenation

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Nov 5 22:14:08 UTC 2018


On Monday, November 5, 2018 2:49:32 PM MST bachmeier via Digitalmars-d 
wrote:
> On Monday, 5 November 2018 at 21:11:27 UTC, Jonathan M Davis
>
> wrote:
> > I don't know how reasonable it is to fix it at this point, much
> > as I would love to see it fixed.
>
> It's hard for me to see how it would be reasonable to not fix it.
> This is one of those ugly parts of the language that need to be
> evolved out of the language. If there's a reason to support this,
> it should be done with a compiler switch. I'm pretty sure that
> this was one of the weird things that hit me when I started with
> the language, it was frustrating, and it didn't make a good
> impression.

It really comes down to what code would break due to the change, how that
code breakage could be mitigated, what the transition process would look
like, and how Walter views the issue at this point. Historically, he has not
seen this as a problem like many of us have, but his views have evolved
somewhat over time. However, he's also become far more wary of breaking code
with language changes.

If this change were proposed in a DIP, a clean transition would be required,
and if a compiler flag were required, I don't know that it would ever
happen. I don't recall a single transition that has required a compiler
switch in D that has ever been completed. Some that have had a compiler
switch to get the old behavior back have worked, but stuff like -property or
-dip25 have never reached the finish line. -dip25 may yet get there given
how it's tied into -dip1000, and I expect that Walter will find a way to
push -dip1000 through given its importance for @safe, but it's still an open
question how on earth we're going to transition to DIP 1000 being the normal
behavior given how big a switch that is.

So, if someone can figure out how to cleanly transition behavior to get rid
of the implicit conversion between character types and integer types without
needing a -dipxxx switch to enable the new behavior, and they can argue it
well enough to convince Walter, then we may very well get there, but
otherwise, I expect that we're stuck. Either way, I think that we have to
see how https://github.com/dlang/DIPs/blob/master/DIPs/DIP1015.md does
first. If _that_ can't get through, I don't think that a DIP to fix implict
conversions and char stands a chance. I'm currently expecting that DIP to be
accepted, but you never know.

- Jonathan M Davis





More information about the Digitalmars-d mailing list