[Development] Source break policy for function overloads

[Marc Mutz]

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 <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts