I don’t see the problem here. Ranges library operates on views only, so there
*should be* (I am just not aware of it’s name) the type that corresponds to the
«forward access iterator» (well, in case of QSet, that would be bidirectional
but not random access iterator) range.
If there’s no such view, it’s quite easy to implement it - it’s simply a pair
of iterators.
The disadvantage here is that such a view doesn’t gives the same flexibility as
std::span does. i.e. it is still not possible to replace QSet with
std::unordered_set, so we don’t have much gain compared to returning QSet /
const QSet &.
So, as I said, I do not see the problem. Can we always return views? Yes. Do
they gives us benefits in every case? No.
Ivan
> 14 мая 2020 г., в 02:15, Thiago Macieira <thiago.macie...@intel.com>
> написал(а):
>
> On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
>> std::span<Product> Project::productsSpan() const & { return d->products; }
>> std::span<Product> Project::productsSpan() const && = delete;
>
> Now implement either or both of these functions if internally you have a
> QSet<Products>.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel System Software Products
>
>
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
