[Development] Recommended way to take in strings

[Giuseppe D'Angelo]

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.dangelo at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230610/64c5d2f4/attachment.bin>