On Fri, Jan 9, 2026 at 1:53 PM Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]> wrote:

On Fri, 9 Jan 2026 at 18:49, Jonathan Wakely <cxx_at_[hidden]> wrote:

 

But it seems like a badly-designed overload set anyway, since you have one function name "interest" but the functions do two different things. It would probably be better if you had names that make what they do clearer, calc_interest_factor and calc_interest_major_minor or something (I have no idea what the "minor" argument means, so better names are probably possible).

https://abseil.io/tips/148 is highly relevant here (and to the bugs described by David Crocker elsewhere in the thread):

 “Use overloaded functions (including constructors) only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called.”

If you have overloads with the same number of parameters, they had damn well better be (mostly) interchangeable, e.g. it doesn't really matter if you call std::pow(5.0, 2L) instead of std::pow(5.0, 2.0) because they do the same thing. If they perform different operations based on the type of the second argument, that's a bad API.

Yep. As Titus Winters said many years ago now, "The atom of C++ API design is the overload set [not the individual function]."

I also have a talk on this from the pandemic years: "When should you give two things the same name?" (C++Now 2021), which was based on my October 2020 blog post "Inheritance is for sharing an interface (and so is overloading)."  See also my next post, "A very short war story on too much overloading," which relates specifically to conversions-to-bool.

I recently revisited implicit-conversion-to-bool in "What breaks without implicit T*-to-bool conversion?" — the answer is, a few things but not much.

–Arthur

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