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

List:       kde-frameworks-devel
Subject:    Challenge: adding new method overloads when existing consumers use {} with args
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2022-07-23 15:20:08
Message-ID: 1829654.CQOukoFCf9 () klux
[Download RAW message or body]

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?

Cheers
Friedrich


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