I believe concepts only work inside of templates.

 

From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Robin Savonen Söderholm via Std-Proposals
Sent: Friday, January 9, 2026 10:36 AM
To: C++ Proposals <std-proposals_at_[hidden]>
Cc: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>
Subject: Re: [std-proposals] resolving function overloading ambiguity for bool arguments

 

You already can:

 

void foo(double arg1, std::same_as<bool> auto arg2)...

 

On Fri, Jan 9, 2026, 18:18 David Brown via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:



On 09/01/2026 17:37, Steve Weinrich via Std-Proposals 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 is not ambiguous - the best fit overload will be used. The rules
for overload resolution are a bit complicated, but in this case the
results are clear.

<https://en.cppreference.com/w/cpp/language/overload_resolution.html>

>
> 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);
>

To me, a bigger issue is when you /don't/ have overloads :


        void interest (double arg1, bool minor);

In this situation, the implicit conversion of an int to a bool for
"interest(5.5, 5)" is likely to be an error on the programmer's side,
but it is accepted without question by C++ compilers. To avoid this,
some people use "strong bool" types that have much stricter implicit
conversions, such as :

class Bool {
     bool v;
public :
     constexpr Bool(bool v) noexcept : v(v) {}
     Bool(auto v) = delete;
     explicit constexpr operator bool() const noexcept { return v; }
};

Then you can declare the function :

        void interest (double arg1, Bool minor);

and use it with a bool type as the second argument, but not with another
type that has an implicit conversion to bool.

An alternative way to block non-bool calls would be to write :

        void interest (double arg1, bool minor);
        void interest (double arg1, auto) = delete;


But it would be very nice (IMHO) if you could just write :

        void interest (double arg1, explicit bool minor);

and get the same effect (that is, a function candidate would not be
considered "viable" in overload resolution if the second argument
required an implicit conversion sequence to the specified type).

-- 
Std-Proposals mailing list
Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> 
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals