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

[Harald Sitter]

On Mon, Jul 25, 2022 at 2:23 PM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> Am Montag, 25. Juli 2022, 10:19:39 CEST schrieb David Redondo:
> > Am Samstag, 23. Juli 2022, 17:20:08 CEST schrieb Friedrich W. H. Kossebau:
> > Adding such an overload as in your example is source incompatible
> > regardless. See also our guidelines.
> > https://community.kde.org/Policies/
> > Binary_Compatibility_Issues_With_C%2B%2B#Note_about_ABI
> >
> > You cannot...
> >   For existing functions of any type:
> >     Add an overload (binary compatible, but not source compatible: it makes
> > &func ambiguous). Adding overloads to already overloaded functions is ok
> > (since any use of &func already needed a cast).
>
> Indeed, this also was not on the radar of all those adding the overloads to
> KMessageBox recently, will discuss elsewhere.
>
> But let's try to improve the example then, as the new challenge by {} still
> exists:
>
> Given a class C with methods fpo() and foo(A a):
> --- 8< ---
>     class C
>     {
>     public:
>         void foo();
>         void foo(A a);
>     };
> --- 8< ---
>
> Now you want to add an overload, to serve further use-cases as requested by
> API consumers:
> --- 8< ---
>         void foo(B b);
> --- 8< ---
>
>
> But there is existing consumer code, making use of C++17, which calls
> --- 8< ---
>     C c;
>     c.foo({});
> --- 8< ---
>
> So the new overload will not be source-compatible and break existing code.
>
> What to do about {} being a API addition roadblocker here in C++17 worlds?

We cannot do anything about it. Either we consider it SIC and cannot
add overloads, or we don't and consider it a consumer problem. Seeing
as it breaks existing code I'm sure the way to go is to amend the rule
David mentioned to just outright discourage overloads. A bit
impractical, but then all of source compatibility is a bit impractical
^^

HS