[libcxx-commits] [PATCH] D101922: [libcxx][iterator] adds `std::ranges::advance`
Louis Dionne via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Sat May 8 09:36:15 PDT 2021
ldionne added inline comments.
================
Comment at: libcxx/include/__iterator/primitives.h:10
+
+#ifndef _LIBCPP___ITERATOR_PRIMITIVES_H
+#define _LIBCPP___ITERATOR_PRIMITIVES_H
----------------
Why is this header named that way? Shouldn't this be `__iterator/advance.h` to be consistent with what we've done so far? We've never named headers after the section of the standard that they roughly represent, and I don't think we should start doing that. Section names can change, they don't necessarily best represent what's in the file, and it goes against what we've started doing consistently.
================
Comment at: libcxx/include/__iterator/primitives.h:39
+ template <signed_integral _Tp>
+ [[nodiscard]] static constexpr make_unsigned_t<_Tp> __abs(_Tp const __n) noexcept {
+ auto const __unsigned_n = __to_unsigned_like(__n);
----------------
Drop `[[nodiscard]]` (as discussed offline). Also applies to most other places where you use it.
Also, should this be promoted to a more general utility?
And also, this may be obvious to you, but why don't we simply use `std::abs`? Is it because http://eel.is/c++draft/iterator.primitives#range.iter.op.advance-6.1.1 uses absolute value in math notation (which is well-defined for all inputs), whereas `std::abs` is UB if the absolute value can't be represented in the return type?
================
Comment at: libcxx/include/__iterator/primitives.h:60-70
+ while (__n > 0) {
+ --__n;
+ ++__i;
+ }
+
+ // Otherwise, decrements `i` by `-n`.
+ if constexpr (bidirectional_iterator<_Ip>) {
----------------
I understand why this works, but I find it's a slightly confusing way to write this. Instead, Maybe `else if constexpr (is_bidirectional_iterator<_Ip>) { handle bidirectional case } else { handle-forward-only-case }`.
It's not as clever, but maybe easier to understand?
================
Comment at: libcxx/include/iterator:550
+template <class _InputIter, class _Distance,
+ class = typename enable_if<is_integral<decltype(_VSTD::__convert_to_integral(declval<_Distance>()))>::value>::type>
inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX14
----------------
What's the rationale for this change? I remember playing around the same area here: https://reviews.llvm.org/D81425, it might be useful to read that again for context. I don't have enough time to form an opinion again right now unfortunately.
If we decide to keep it, we should add a test. IIUC that would be considered a libc++ extension at this point based on glancing at https://reviews.llvm.org/D81425 again quickly.
================
Comment at: libcxx/test/support/test_iterators.h:727
+
+ [[nodiscard]] constexpr I base() const& requires std::copyable<I> { return base_; }
+
----------------
`s/[[nodiscard]]//g`
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D101922/new/
https://reviews.llvm.org/D101922
More information about the libcxx-commits
mailing list