Strange implicit conversion integers on concatenation

[H. S. Teoh]

On Mon, Nov 05, 2018 at 05:43:19PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> It's not just ints to chars, but chars to wchars or dchars, and wchars
> to dchars.
> 
> Basically a character type should not convert from any other type.
> period.  Because it's not "just a number" in a different format.

+1.  I recall having this conversation before.  Was this ever filed as a
bug?  I couldn't find it this morning when I tried to look.


> Do we need a DIP? Probably. but we have changed these types of things
> in the past from what I remember (I seem to recall we had at one point
> implicit truncation for adding 2 smaller numbers together). It is
> possible to still fix.
[...]

If it's possible to fix, I'd like to see it fixed.  So far, I don't
recall hearing anyone strongly oppose such a change; all objections
appear to be only coming from the fear of breaking existing code.

Some things to consider:

- What this implies for the "if C code is compilable as D, it must have
  the same semantics" philosophy that Walter appears to be strongly
  insistent on.  Basically, anything that depends on C's conflation of
  char and (u)byte must either give an error, or give the correct
  semantics.

- The possibility of automatically fixing code broken by the change
  (possibly partial, leaving corner cases as errors to be handled by the
  user -- the idea being to eliminate the rote stuff and only require
  user intervention in the tricky cases).  This may be a good and simple
  use-case for building a tool that could do something like that.  This
  isn't the first time potential code breakage threatens an otherwise
  beneficial language change, where having an automatic source upgrade
  tool could alleviate many of the concerns.

- Once we start making a clear distinction between char types and
  non-char types, will char types still obey C-like int promotion rules,
  or should we consider discarding old baggage that's no longer so
  applicable to modern D?  For example, I envision that this DIP would
  make int + char or char + int illegal, but what should the result of
  char + char or char + wchar be?  I'm tempted to propose outright
  banning char arithmetic without casting, but for some applications
  this might be too onerous.  If we continue follow C rules, char + char
  would implicitly promote to dchar, which arguably could be annoying.


T

-- 
"Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra