[Development] How qAsConst and qExchange lead to qNN

[Thiago Macieira]

On Monday, 14 November 2022 18:32:36 PST Giuseppe D'Angelo via Development 
wrote:
> I'm not sure what is meant here. I was just pointing out that
> overloading a function with QString and QStringView (or QAnyStringView
> for that matter) is just a historical accident:
> 
> * we have an "old" API that takes QString
> * we realize it doesn't _have to_ (e.g. string never stored, etc.)

Mind you we need to determine not "it doesn't need to store now" but "it will 
never need to store". We have to know ahead of time that we won't need this. 
And if we can't overload, then we need to know this even beyond the next major 
version.

> * we want to replace it with a "newer" API that takes QStringView. We
> can't literally *replace* it (binary, and also, minor, source
> compatibility). So we have to add a QStringView overload and keep both
> for the entire major version.

We can hide the existing one with QT_REMOVED_SINCE. So we can, effectively, 
replace.

> * Now, if we have a QString(const char16_t *) constructor, this
> overloading break SC when someone calls the API with a u"" literal, and
> that's super-annoying.

Right.

> But the point is that if we developed the API from scratch today, we'd
> likely not even had the QString overload to begin with -- we would have
> averted the whole issue.

I don't think that's necessarily true. But that's an orthogonal problem.

Your question remains:

> We've found a robust solution to this problem via the removed_api
> mechanism, which is going to keep the QString overload, but hide it from
> clients. (At least, I *think*.) This will make calls passing u""
> literals to keep working just fine. So what other concern is there for
> not allowing this QString construction?


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