Deprecate implicit conversion between signed and unsigned integers (page 2)

February 06

Re: Deprecate implicit conversion between signed and unsigned integers

Posted by Quirin Schroll
in reply to Kagamin

Permalink

Quirin Schroll

Posted in reply to Kagamin

Permalink

On Thursday, 6 February 2025 at 16:48:27 UTC, Kagamin 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:

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

I once ported a 32 bit C++ application to 64 bit. The code was

uint32_t found=str1.find(str2);
if(found==string::npos)return;
str3=str1.substr(0,found);

One can say the problem is in narrowing conversion, but there's still the fundamental problem that npos of different widths are incompatible.

The fault 100% lies in converting std::size_t (which is std::uint64_t on all(?) 64-bit platforms) to std::uint32_t.

You could also say it’s bad that the compiler didn’t warn you about a non-trivial expression that will always be false because a std::uint32_t simply can’t be std::string::npos (which is ~std::uint64_t{} guaranteed by the C++ Standard). Clang warns on these, GCC doesn’t.

You really can’t blame std::uint32_t converting to std::uint64_t. That is completely reasonable.

Having a function that searches an array for a value and returns the index of the array if found, and -1 if not found, is not a good practice. An index being returned should be size_t, and the not-found value should be size_t.max. See my other post on recommendations for selecting integral types.

On 2/6/2025 7:18 AM, Quirin Schroll wrote: > 4. Micro-lossy narrowing conversions: > * `int`/`uint` → `float` > * `long`/`ulong` → `float`/`double` We already do VRP checks for cases: ``` float f = 1; // passes float g = 0x1234_5678; // fails ```

I forgot to mention: ``` int popcount(int x); ``` ``` uint y = ...; popcount(y); // do you really want that to fail? ``` Let's fix it: ``` int popcount(uint x); ``` ``` int y = ...; popcount(y); // now this fails ```

On Thursday, 6 February 2025 at 20:44:46 UTC, Walter Bright wrote: > Having a function that searches an array for a value and returns the index of the array if found, and -1 if not found, is not a good practice. All options suck, -1 should suck least; size_t is insane in the 64bit era no one has that much ram, no one has that much ram for compressed bools of 2^63 bits

On 2/6/2025 12:59 PM, monkyyy wrote: > All options suck, -1 should suck least; size_t is insane in the 64bit era no one has that much ram, no one has that much ram for compressed bools of 2^63 bits As D is also a systems programming language, it provides access to the model the hardware implements.

On 07/02/2025 9:55 AM, Walter Bright wrote: > I forgot to mention: > > ``` > int popcount(int x); > ``` > ``` > uint y = ...; > popcount(y); // do you really want that to fail? > ``` > > Let's fix it: > > ``` > int popcount(uint x); > ``` > ``` > int y = ...; > popcount(y); // now this fails > ``` Within the last couple of days on Twitter the C community has mentioned that they'd like implicit conversion for numeric types to static arrays. That could resolve this quite nicely. ```d int popcount(ubyte[4]); int y = ...; popcount(y); uint z = ...; popcount(z); ``` An explicit cast with ``ref`` could go the other way.

On Friday, 7 February 2025 at 01:30:31 UTC, Walter Bright wrote: > On 2/6/2025 12:59 PM, monkyyy wrote: >> All options suck, -1 should suck least; size_t is insane in the 64bit era no one has that much ram, no one has that much ram for compressed bools of 2^63 bits > > As D is also a systems programming language, it provides access to the model the hardware implements. Do any of the embedded projects have working slices? Are there no ways to make size_t only signed on 64 bit machines, or as a flag? I dont even know what the argument is for when that 64th bit will be used.

Forums