Sadly, C++ is fundamentally broken in this area, because of the amazingly stupid and IMO unforgiveable decision to support both implicat type conversion and overloading in the same context. This was already known to be a bad idea in the 1960s, which is why Algol68 restricted automatic type conversions where overloading was supported.

I work in mission- and safety-critical software. We use a static analyser to enforce the rule that if a function/operator/constructor call can potentially match more than one declaration, the call is not allowed unless it matches one of them exactly, i.e. without implicit type conversions.

In a job which involved applying static analysis to a few million lines of C++ code, this was the biggest single source of bugs detected. In more than 100 places, the function that was actually called was not the one that the programmer intended, leading to incorrect behaviour.

I can't see a way to resolve this other than to break backwards compatibility by restricting implicit type conversions in the presence of overloading.

9 Jan 2026 16:41:40 Brian Bi via Std-Proposals <std-proposals@lists.isocpp.org>:

On Fri, Jan 9, 2026 at 11:38 AM Steve Weinrich via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Consider two methods:

void interest (double arg1, bool minor);

void interest (double arg1, int factor);

The call: interest(5.5, 5); is ambiguous because 5 will freely convert to a bool.

No it's not.

I was wondering what y’all would think of narrowing this behavior by this addition:

void interest (double arg1, explicit bool minor);

Potentially, this could be applied to all arguments:

void explicit interest (double arg1, bool minor);

Thanks,

Steve

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--

Brian Bi