On 09/11/2022 20:25, Thiago Macieira wrote:
Our API should default to passing QStrings for simplicity and not to confuse the user. The fact that I cannot wrote: foo(u"bar'); if foo takes a QString is MESSED UP.
Is this because we deliberately didn't add a QString(const char16_t *) constructor, to prevent ambiguities in case we have overloads like these:
void f(QString) void f(QStringView) ?(We end up with these overload sets because right now we have tons of f(QString), and we're slowly moving them to f(QStringView) if it does make sense for them. Due to the BC promise we can't just _remove_ f(QString).)
However: doesn't the new "removed API" system change the status quo? The point of the new system is to allow us to preserve BC, while always presenting only one of the two functions (the most recent) to client code. f(u"foo") would therefore still compile and don't incur in the ambiguity.
(Surely, it's not 100% API compatible, but it would be a SIC A). Thanks, -- Giuseppe D'Angelo | [email protected] | 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 [email protected] https://lists.qt-project.org/listinfo/development
