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
smime.p7s
Description: S/MIME Cryptographic Signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
