Jump to page: 1 2 3
Thread overview
Deprecate implicit conversion between signed and unsigned integers
6 days ago
Paul Backus
5 days ago
Quirin Schroll
5 days ago
Walter Bright
5 days ago
Kagamin
5 days ago
Quirin Schroll
5 days ago
Walter Bright
5 days ago
monkyyy
5 days ago
Walter Bright
5 days ago
monkyyy
5 days ago
Kagamin
4 days ago
DLearner
6 days ago
Walter Bright
5 days ago
Walter Bright
5 days ago
Atila Neves
6 days ago
Dom DiSc
5 days ago
Kagamin
February 03

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

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

>

D inherited these implicit conversions from C and C++, where they are widely regarded as a source of bugs.

[...]

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

February 03

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

>

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

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

>

D inherited these implicit conversions from C and C++, where they are widely regarded as a source of bugs.

[...]

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

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.

February 04

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

>

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

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

>

D inherited these implicit conversions from C and C++, where they are widely regarded as a source of bugs.

[...]

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

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

  • floatdoublereal
  • signed integer → bigger signed integer
  • unsigned integer → bigger unsigned integer

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

February 05

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

>

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

>

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

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

>

D inherited these implicit conversions from C and C++, where they are widely regarded as a source of bugs.

[...]

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

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.

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.

6 days ago

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

>

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

Sounds like churn.

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

6 days ago

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

>

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

  • floatdoublereal
  • signed integer → bigger signed integer
  • unsigned integer → bigger unsigned integer

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

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

  • ushortint
  • longfloat

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

6 days ago
[I'm not sure why a new thread was created?]

This comes up now and then. It's an attractive idea, and seems obvious. But I've always been against it for multiple reasons.

1. Pascal solved this issue by not allowing any implicit conversions. The result was casts everywhere, which made the code ugly. I hate ugly code.

2. Java solve this by not having an unsigned type. People went to great lengths to emulate unsigned behavior. Eventually, the Java people gave up and added it.

3. Is `1` a signed int or an unsigned int?

4. What happens with `p[i]`? If p is the beginning of a memory object, we want i to be unsigned. If p points to the middle, we want i to be signed. What should be the type of `p - q`? signed or unsigned?

5. We rely on 2's complement overflow semantics to get the same behavior if i is signed or unsigned, most of the time.

6. Casts are a blunt instrument that impair readability and can cause unexpected behavior when changing a type in a refactoring. High quality code avoids the use of explicit casts as much as possible.

7. C behavior on this is extremely well known.

8. The Value Range Propagation feature was a brilliant solution, that resolved most issues with implicit signed and unsigned conversions, without causing any problems.

9. Array bounds checking tends to catch the usual bugs with conflating signed with unsigned. Array bounds checking is a total winner of a feature.

Andrei and I went around and around on this, pointing out the contradictions. There was no solution. There is no "correct" answer for integer 2's complement arithmetic.

Here's what I do:

1. use unsigned if the declaration should never be negative.

2. use size_t for all pointer offsets

3. use ptrdiff_t for deltas of size_t that could go negative

4. otherwise, use signed

Stick with those and most of the problems will be avoided.

6 days ago

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

>

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

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

>

D inherited these implicit conversions from C and C++, where they are widely regarded as a source of bugs.

[...]

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

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?

6 days ago
On 07/02/2025 12:07 AM, Dom DiSc wrote:
> On Monday, 3 February 2025 at 18:40:20 UTC, Atila Neves wrote:
>> https://forum.dlang.org/post/pbhjffbxdqpdwtmcbikh@forum.dlang.org
>>
>> On Sunday, 12 May 2024 at 13:32:36 UTC, Paul Backus wrote:
>>> D inherited these implicit conversions from C and C++, where they are widely regarded as a source of bugs.
>>>
>>> [...]
>>
>> My bias is to not like any implicit conversions of any kind, but I'm not sure I can convince Walter of that.
> 
> I think most of the problems with these implicit conversions would be gone if we make this work:
> 
> ```d
>     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?

We should revisit this once editions are accepted.

It sounds reasonable to disable comparisons as long as VRP is kicking in to allow it selectively.

5 days ago

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

>

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

>

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

  • floatdoublereal
  • signed integer → bigger signed integer
  • unsigned integer → bigger unsigned integer

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

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

  • ushortint
  • longfloat

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

I even think that implicit conversions from integral to floating-point type are bad, considering that intfloat and longdouble aren’t lossless in general.

Here’s an attempt to classify:

  1. Definitely okay implicit conversions:
    • floatdoublereal
    • byteshortintlong
    • ubyteushortuintulong
  2. Probably okay implicit conversions:
    • ubyteshortintlong
    • ushortintlong
    • uintlong
  3. Somewhat contentious implicit conversions:
    • byte/ubyte/short/ushortfloatdoublereal
    • int/uintdoublereal
    • long/ulongreal
  4. Micro-lossy narrowing conversions:
    • int/uintfloat
    • long/ulongfloat/double
  5. Bit-pattern-preserving value-altering conversions:
    • byteubyte
    • shortushort
    • intuint
    • longulong
  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.
« First   ‹ Prev
1 2 3