Challenge: adding new method overloads when existing consumers use {} with args

[Friedrich W. H. Kossebau]

(David, somehow your emails do not make it from the mailinglist to my inbox 
sadly, no idea yet why. Saw your email by chance on the list web interface, 
and tosky forwarded it manually to me, so I can reply now here. So might miss 
out more :()

Am Samstag, 23. Juli 2022, 20:26:47 CEST schrieb David Hurka:
> > Had not yet thought about this challenge myself before, so curious what
> > people think can be done here?
> 
> Would it work to make foo(B) less tasty for implicit conversion with
> std::variant (or another small wrapper)?
> 
> ```
> class C
> {
> public:
>     void foo(A a);
>     /** @since ... */
>     void foo(std::variant<B> b);
> };
> ```
> 
> My assumption is that std::variant requires a “user-defined conversion” [1],
> and therefore an explicitly provided B object can be implicitly converted
> to a std::variant<B>, but the ambiguous {} can’t.

Thanks, also interesting.

Drawbacks I see, as with the std::enable_if_t one:
* new overload method (and any further ones) will stay special
* existing consumer code using {} is not that simple to map by human readers
  as to which overload will be used
* needs C++17, so needs some additional markup when used in KF5 headers for 
those using them with C++11-compat needs

Added to set of ideas to experiment more with in any case.

Cheers
Friedrich