Deprecate implicit conversion between signed and unsigned integers

[Quirin Schroll]

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.