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 > intended. > > 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 WONTFIX. I agree. 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 versions, and 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. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
