[Development] Source break policy for function overloads

Simon Hausmann Simon.Hausmann at qt.io
Wed Jul 13 16:30:52 CEST 2016


Hi,


I suppose that if this is the first time an overload is added, then the risk of ambiguity exists. It

seems that this is the case here. If released API has overloads and a new overload is added,

then the caller code using QObject::connect would already use qOverload or similar, right? In that

case perhaps it is not necessary to document the addition as source compatibility may be preserved.



It all comes down to the question: What impression do we want to give people when they upgrade to

a newer version of Qt?



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
Sent: Wednesday, July 13, 2016 4:16:39 PM
To: development at qt-project.org
Subject: Re: [Development] Source break policy for function overloads

Il 13/07/2016 15:55, Simon Hausmann ha scritto:
>
> I think if we allow source compatibility breakages like the one here
> (overloaded slot added), then I think
>
> it should require a prominent notice in the changelog / release notes.

Note that setInterval is not even a slot (but an overload of start(), a
slot, was also added in the same commit). Do we need to add changelog
notes for *any* overload added to free functions or QObject subclass
member functions?

Cheers,
--
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/9bc7e0a6/attachment.html>


More information about the Development mailing list