This is part of the work to make it possible specialize traits types for
a view, like __segmented_iterator_traits.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Unit Tests
Event Timeline
Comment Actions
They should be. I've listed the ones that didn't have the iterator outside the class a few weeks ago and these are the last ones.
Comment Actions
There is a GCC failure on the CI that exposed two interesting issues:
- (Found by @huixie90) Moving iterator classes out of the view class can lead to a noticeable difference in behavior. What was previously template parameters of the view (but not the iterator) becomes template parameters of the iterator. This can add more namespaces and associated classes via ADL when doing overload resolution for the iterator. A Godbolt demo from @huixie90: https://godbolt.org/z/sEzjnnEeK
- There is a divergence in behavior between GCC on one side and Clang and MSVC on the other side (https://godbolt.org/z/bbxv75aE7):
template <class T> concept Foo = requires(T val) { val == val; }; template <class T> struct Bar {}; template <class T> bool operator==(const Bar<T>&, const Bar<T>&); // Overload 1 template <class T> requires Foo<Bar<T>> bool operator==(const Bar<T>&, int); // Overload 2 static_assert(Foo<Bar<int>>);
In this example, Clang and MSVC would not instantiate overload 2 of operator== when evaluating the Foo concept. GCC, on the other hand, instantiates overload 2 which leads to infinite recursion since overload 2 depends on Foo.
Comment Actions
We ended up deciding to move iterators back into classes -- abandoning in favor of https://reviews.llvm.org/D143324.