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