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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
