[Development] Source break policy for function overloads
marc.mutz at kdab.com
Wed Jul 13 20:10:21 CEST 2016
On Wednesday 13 July 2016 18:47:28 Thiago Macieira wrote:
> We do have this policy since 5.0 that we have to be careful about
> overloads due to the connect syntax. The breakage was accidental and not
> I did intend to add overloads, as they're nice to use, I just hadn't
> considered the consequences.
When I reported an SC breakage from an added overload in Qt 4, I got back a
There are two problems with adding overloads:
1. You may make existing calls ambiguous.
This should be prevented as much as possible (by adding sufficiently many
additional overloads to restore unambiguity).
2. You can make taking a function pointer ambiguous when adding the 2nd
overload. This cannot be prevented, and we shouldn't strive to
(effectively) ban overloads because of it. If examples and other docs
would consistently use qOverload, instead of pretending that the naked
addressof operator is sufficient, our users wouldn't hit the compiler
errors mentioned by Ola.
It should also be noted that there are two categories of SiCs:
a. those that can be fixed client-side without breaking compat with older Qt
b. those which cannot
IMO, SiCs of type (a) are acceptable, those of type (b) are obviously no-no's.
Adding an overload (both cases: 1 + 2 above) is type (a), so is acceptable.
Adding explicit to a ctor that should have been but wasn't is also SiC Type
(a). In these cases, code that breaks is code that deserves to be broken,
because it was brittle.
Renaming a public inline function of a non-exported class is BC, but SiC Type
(b), so not acceptable.
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - Qt, C++ and OpenGL Experts
More information about the Development