https://forum.dlang.org/post/pbhjffbxdqpdwtmcbikh@forum.dlang.org

On Sunday, 12 May 2024 at 13:32:36 UTC, Paul Backus wrote:

My bias is to not like any implicit conversions of any kind, but I'm not sure I can convince Walter of that.

On Monday, 3 February 2025 at 18:40:20 UTC, Atila Neves wrote:

That's why I focused my proposal on the specific conversions that are the most error-prone. I don't think we'll ever convince Walter to get rid of integer promotion in general, but there's a chance we can convince him to get rid of these specific conversions.

On Monday, 3 February 2025 at 18:40:20 UTC, Atila Neves wrote:

Any implicit conversions? I’d boldly claim the following conversions are unproblematic:

• float → double → real
• signed integer → bigger signed integer
• unsigned integer → bigger unsigned integer

And it would be really annoying to have to explicitly cast them.

On Monday, 3 February 2025 at 19:30:14 UTC, Paul Backus wrote:

Those are annoying, yes. Especially unary operators. If you asked me right now what ~x returns on a small integer type, I honestly don’t know.

D has C’s rules because of one design decision early on: If it looks like C, it acts like C or it’s an error.

On Monday, 3 February 2025 at 18:40:20 UTC, Atila Neves wrote:

Sounds like churn.

Even the => syntax prevents to use old compilers with new package and cause churn in the DUB ecosystem.

On Tuesday, 4 February 2025 at 16:29:22 UTC, Quirin Schroll wrote:

In general, implicit conversions that preserve the value range of the original type are ok. So, for example:

• ushort → int
• long → float

The reason that conversions like int → uint and uint → int are problematic is that the value range of the original type does not fit into the value range of the target type.

On Monday, 3 February 2025 at 18:40:20 UTC, Atila Neves wrote:

I think most of the problems with these implicit conversions would be gone if we make this work:

   byte a= -5;
   ulong b = 1_000_000_000_000;
   assert(a < b); // fails

And we already do have a solution for this (see https://issues.dlang.org/show_bug.cgi?id=259), but Walter refuses it, because it will break code that relies on this bug.
How much less likely is it to convince him of your proposal?

On Wednesday, 5 February 2025 at 16:29:25 UTC, Paul Backus wrote:

I even think that implicit conversions from integral to floating-point type are bad, considering that int → float and long → double aren’t lossless in general.

Here’s an attempt to classify:

1. Definitely okay implicit conversions:
   • float → double → real
   • byte → short → int → long
   • ubyte → ushort → uint → ulong
2. Probably okay implicit conversions:
   • ubyte → short → int → long
   • ushort → int → long
   • uint → long
3. Somewhat contentious implicit conversions:
   • byte/ubyte/short/ushort → float → double → real
   • int/uint → double → real
   • long/ulong → real
4. Micro-lossy narrowing conversions:
   • int/uint → float
   • long/ulong → float/double
5. Bit-pattern-preserving value-altering conversions:
   • byte ↔ ubyte
   • short ↔ ushort
   • int ↔ uint
   • long ↔ ulong
6. Lossy narrowing conversions:
   • The reverse of any “→” above.

It appears to me that you can reasonably draw 7 lines (from before 1 to after 6). Examples for what existing languages do (to my knowledge):

• Haskell draws the line at 0/1. It has no implicit conversions whatsoever.
• C# draws the line at 4/5.
• D draws the line at 5/6.
• C/C++ draws the line at 6/7.