[Development] Views in APIs (was: Re: QString and related changes for Qt 6)
thiago.macieira at intel.com
Thu May 14 21:00:22 CEST 2020
On Thursday, 14 May 2020 04:20:43 PDT Иван Комиссаров wrote:
> 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.
You're missing the point. I want you to implement it without changing your
Or, in different words: choose one return type for your non-inline function
that you can be sure to support for the next 7 years, regardless of internal
modifications to your data store.
> 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.
Should we do it? Almost never.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development