[Development] How qAsConst and qExchange lead to qNN

[Jaroslaw Kobus]

> 1. Use overloads for methods that take views or spans. In new API we can
> omit the methods that take owning containers. If the overload set grows
> out of hand, don't add the view/span alternative until we can remove
> something. By Thiago's argument, that means not to convert existing
> methods to QStringView for now.
> 
> 2. Use the postfix "View", "Span" or "Generator" for methods that return
> views, spans or generators rather than owning containers. This way it's
> harder for users to mess up the life time.

Ad 1. Having overloads sometimes causes issues, like e.g. can't be a slot due to
ambiguity when making a signal-slot connection. For this reason I believe that
most (all?) of signals overloads were removed in Qt 6. The similar issues may
be encountered when using QtConcurrent API.

So, if you suggest suffix for Ad 2, maybe make it consistent and use the same suffix for Ad 1, too?

Disclaimer: I'm not saying that adding "view" and "span" functionality into Qt is a good idea.
It's a bit like giving a raw pointer of some part of your internal data into the public API
(however, wrapped nicely with a fashionable envelope - so it shouldn't look so bad, right?).
Yeah, in some cases it may save 1 ns for containers having thousands of items. But will it make
e.g. rendering QGradient faster (when gradient stops are wrapped with span, as Mark suggested)?
Especially, as it was mentioned, typical case is 2, max 3 items?

Qt was always cute, because its API was designed so that it's really hard to mess things up.
It looks like we are slowly dropping this beautiful keynote, unfortunately.

Jarek