[Development] C++20 std::span @ Qt (was: Re: C++20 @ Qt)

[Marc Mutz]

Hi,

If you've ever used std::span (or gsl::span, or llvm::ArrayRef, or ...), 
you'll agree that it's nothing short of addictive. And for Qt, in 
particular, it's a step toward escaping the lock-in caused by owning NIH 
vocabulary types.

As such, std::span is most useful when used at the ABI boundary, because 
it's a way to type-erase the source container, which is necessary when 
taking implementation behind the ABI boundary (the alternative, 
templates, keep the implementation between the API and the ABI 
boundaries, causing code duplication can necessitating re-compiles when 
the Qt implementation changes, as opposed to just replacing the Qt 
libraries underneath the application).

So Qt would benefit from use of std::span more than most other C++ 
libraries. Yet, we didn't reach consensus[1] on allowing C++20 types in 
the Qt ABI. Also, with the move to C++20 looking increasingly unlikely 
to happen in Qt 6.6, we're facing another LTS era without this useful tool.

After presenting this internally for the third time some time ago, I 
therefore came to the conclusion that a QSpan wouldn't be quite so bad.

Now, I'd be the first to argue against another NIH reimplementation of a 
std library feature, but in this case, the situation is a bit different: 
spans are non-owning (what once was called a "view"), so they don't 
create the impedance mismatch that an owning NIH vocabulary type would 
cause. In particular, QSpan would naturally be implicitly convertible to 
std::span and vice versa, so users could use whatever they want in their 
code, and Qt implementation could use QSpan to provide a consistent API 
between C++17 and C++20. I would even go so far as to accept divergence 
to std::span, because std::span cannot be created from an rvalue owning 
container, and that causes code to be more complicated than it needs to be.

So, since the time to FF for 6.5 is too short, we're considering to add 
a QSpan as private API for 6.5 with the intent to make it public API in 
6.6 and by the next LTS to have rolled it out over the code base.

Opinions? Comments?

Thanks,
Marc

Reference:
- https://bugreports.qt.io/browse/QTBUG-104662
- https://bugreports.qt.io/browse/QTBUG-104663
- https://bugreports.qt.io/browse/QTBUG-108124

[1] 
https://lists.qt-project.org/pipermail/development/2022-January/042151.html