[libcxx-commits] [PATCH] D103171: [libc++] Deprecate std::iterator and remove it as a base class
Louis Dionne via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Wed May 26 13:28:28 PDT 2021
ldionne added a subscriber: zoecarver.
ldionne added inline comments.
================
Comment at: libcxx/include/__memory/raw_storage_iterator.h:45
+ typedef void pointer;
+ typedef void reference;
+
----------------
Mordante wrote:
> Is it intended to change the types of these typedefs and the base class?
Yes, I'm making it standards conforming. I'll add a test too, it seems like we didn't have any.
================
Comment at: libcxx/include/iterator:508
template<class _Category, class _Tp, class _Distance = ptrdiff_t,
class _Pointer = _Tp*, class _Reference = _Tp&>
----------------
Quuxplusone wrote:
> Mordante wrote:
> > Can we remove this class when `_LIBCPP_ABI_NO_ITERATOR_BASES` is defined?
> No. The //existence// of this class doesn't have ABI implications. Also, this class is still present (but deprecated) in C++20. https://timsong-cpp.github.io/cppwp/n4861/depr.iterator.basic#lib:iterator
> If this class were removed from C++23, we'd want to guard it under an //API// macro such as `_LIBCPP_ENABLE_CXX23_REMOVED_ITERATOR`.
That's all correct.
However, going forward, I'll be keen to remove things without guarding them with something like `_LIBCPP_ENABLE_CXX23_REMOVED_ITERATOR`: if you opt-in to a newer standard mode, it means you're OK with the removal. So, for example, I'd be fine if we had not guarded the removal of `std::raw_storage_iterator` by `_LIBCPP_ENABLE_CXX20_REMOVED_RAW_STORAGE_ITERATOR`, but it's fine too cause it's done now.
================
Comment at: libcxx/include/iterator:816
+ typedef void value_type;
+ typedef void difference_type;
+ typedef void pointer;
----------------
Quuxplusone wrote:
> D103101 updates this code for C++20 (where `difference_type` becomes `ptrdiff_t` instead of `void`). Do you want to roll that in here á là D103101, or would you like a followup PR for that?
> Notice that we want to change the value of the //typedef// in C++20, but not alter the name of the //base class// (because that would break ABI).
I was planning on a different review where I update all the iterator types like you did in D103101 (and @zoecarver in his own similar patch).
================
Comment at: libcxx/test/libcxx/iterators/iterator.requirements/iterator.concepts/cpp20_iter_concepts.pass.cpp:49-63
namespace std {
template <>
-struct iterator_traits<MyIter3>
- : std::iterator<OtherTagTwo, char> {};
+struct iterator_traits<MyIter3> {
+ using iterator_category = OtherTagTwo;
+ using value_type = char;
+ using difference_type = std::ptrdiff_t;
+ using pointer = char*;
----------------
Quuxplusone wrote:
> These changes look OK to me, but it would be useful to know what the author was originally trying to test here: this test didn't have anything to do with `std::iterator`'s behavior, did it?
> I suggest drive-by changing
> ```
> namespace std {
> template <>
> struct iterator_traits<MyIter3> {
> ```
> to
> ```
> template <>
> struct std::iterator_traits<MyIter3> {
> ```
> both to save LOC and to avoid reopening namespace std.
I think it's safe to assume there was no intent to test `std::iterator` specifically here. Agreed about the drive-by change.
================
Comment at: libcxx/test/libcxx/iterators/iterator.requirements/iterator.concepts/cpp20_iter_traits.pass.cpp:45-64
namespace std {
template <>
-struct iterator_traits<MyIter>
- : iterator_traits<std::iterator<std::random_access_iterator_tag, char> > {};
+struct iterator_traits<MyIter> {
+ using iterator_category = std::random_access_iterator_tag;
+ using value_type = char;
+ using difference_type = std::ptrdiff_t;
+ using pointer = char*;
----------------
Quuxplusone wrote:
> Same comment here about reopening namespace std.
> But also here it is //clear// that `MyIter` and `MyIter2` are exactly equivalent, and so you can eliminate one of them.
> It looks like the point of this test is to verify that `std::_ITER_TRAITS<T>` is `std::iterator_traits<T>` when `T` specializes `iterator_traits`, and `T` when it doesn't. So the entire test file should look like
> ```
> #include <iterator>
> #include "test_iterators.h"
> struct A : random_access_iterator<int*> {};
> struct B : random_access_iterator<int*> {};
> struct C : random_access_iterator<int*> {};
> struct D : random_access_iterator<int*> {};
> template<> struct std::iterator_traits<B> {};
> template<> struct std::iterator_traits<C> : std::iterator_traits<A> {};
> template<> struct std::iterator_traits<D> : std::iterator_traits<int*> {};
>
> static_assert(std::is_same_v<std::_ITER_TRAITS<int*>, std::iterator_traits<int*>>);
> static_assert(std::is_same_v<std::_ITER_TRAITS<A>, A>);
> static_assert(std::is_same_v<std::_ITER_TRAITS<B>, std::iterator_traits<B>>);
> static_assert(std::is_same_v<std::_ITER_TRAITS<C>, std::iterator_traits<C>>);
> static_assert(std::is_same_v<std::_ITER_TRAITS<D>, std::iterator_traits<D>>);
> ```
> and it should be a .compile.pass.cpp test.
Yup, I agree this is more straightforward.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D103171/new/
https://reviews.llvm.org/D103171
More information about the libcxx-commits
mailing list