[Development] How qAsConst and qExchange lead to qNN

[Thiago Macieira]

On Thursday, 10 November 2022 10:40:35 PST Giuseppe D'Angelo via Development 
wrote:
> 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)
> 
> ?

I think so. I understand why we did it. I just think it's wrong.

> (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).)

And we shouldn't. So we shouldn't be moving to QStringView.

Where it's useful, we can use a Q_WEAK_OVERLOAD. But I insist that we only do 
that where there's a clear performance benefit. Otherwise, keep using 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).

It might, indeed.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering