On 10/06/2023 09:40, A. Pönitz wrote:

For the "rare": I'd like to re-iterate that introducing the/first/  overload
for/anything/  is source-incompatible. I was reminded/again/  of that after
updating to current Qt dev and finding out the hard way that some code that
compiled for ages (using "&QVariant::fromValue<int>") doesn't compile anymore
due to some change that introduced a generic r-value overload for it.

I will forgo any public pondering over (im-)possible setups where r-values for
int parameter have/any/  benefit and simply hope that this will fixed in
the actual 6.7 release, my point/here/  is that overloads should not be added
lightheartedly. Ever.

What this specific incident shows is that we have de facto policies that we don't document / enforce, and that causes users pain. Specifically:

1) do not explicitly specialize function templates passing deducible template parameters;

2) do not take the address of Qt entities, except for QObject-subclass member functions (and even there, I'd be wary if it's not a signal or a slot).


It's obviously Qt's fault if these rules are applied within the QtCore community but unknown to users.

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to