[Development] How qAsConst and qExchange lead to qNN

[Giuseppe D'Angelo]

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 | 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/20221110/5c78b1dc/attachment.bin>