[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Challenge: adding new method overloads when existing consumers use {} with args
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2022-07-25 12:22:45
Message-ID: 1901202.PYKUYFuaPT () klux
[Download RAW message or body]

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?

Cheers
Friedrich



[prev in list] [next in list] [prev in thread] [next in thread]