Il 09/03/21 07:42, André Pönitz ha scritto:
What if there weren't overloads of the actual functions on QString and QStringView?https://wandbox.org/permlink/rdIhbPRdGHuWWxFW
I'm not sure what QStringArg is supposed to be: a view? A container? A type-erased view-or-container?
Anyways, this is the situation where you only have the "right" signatures available. The problem of the current situation is that we have "wrong" signatures around. That is, we have signatures like
f(QString);even for those functions that merely read the string data, so they _could_ use a view; they've just been written like that before we had QStringView, and have not been ported yet. If we didn't care about breaking BC (and marginally about breaking SC) in such a case, we could just *change* the signature to
f(QStringView); // or f(QAnyStringView), f(QStringArg), ...and just achieve the same goal. Instead, we're forced to *add* the overload, therefore causing the possible ambiguities. I don't see how adding QStringArg to the mix would change things here, unless you're aiming at a Qt 7 scenario...?
Thanks, -- 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: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
