Am Samstag, 23. Juli 2022, 17:20:08 CEST schrieb Friedrich W. H. Kossebau:
> Hi,
>
> (cc: kde-frameworks-devel for heads-up, please reply to kde-devel only)
>
> given a class C with a method foo(A a):
> --- 8< ---
> class C
> {
> public:
> 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,
> for what my WE mood brain tells me.
>
> Which spoils the API evolving we have been doing so far e.g. in KDE
> Frameworks quite a bit.
> So far we seem to just have been lucky, but with more consumer code starting
> to make use of C++17 features, the risk has grown and I just ran into this
> the first time ->
> https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/
> e425aaa3025272cb70169354d04dfb3713f9783a#note_491339
>
> Had not yet thought about this challenge myself before, so curious what
> people think can be done here?
>
> Should perhaps the use of list-initializers with arguments in method calls
> be discouraged, at least for plain {} ones, where no type information is
> provided at all?
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).
> Cheers
> Friedrich
David
