[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: Harald Sitter <sitter () kde ! org>
Date: 2022-07-25 12:32:25
Message-ID: CAEc+18EFgCP7+Frb_r2_scHeSH9KaNc6sF1mgsbZVWY7E3rUxA () mail ! gmail ! com
[Download RAW message or body]
On Mon, Jul 25, 2022 at 2:23 PM Friedrich W. H. Kossebau
<kossebau@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic