[libcxx-commits] [PATCH] D94807: [libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter().

Reid Kleckner via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Mon Jan 25 10:58:16 PST 2021

rnk added a comment.

In D94807#2520226 <https://reviews.llvm.org/D94807#2520226>, @ldionne wrote:

> I like this - I find it cleaner than a "private contract" with some specific users that they are allowed to overload `__unwrap_iter`. But I'd like to know why can't we leave that only enabled in C++20 mode. @rnk Would it be acceptable for Chrome to compile with C++20? It seems like an optimization that would justify the work to upgrade?
> As a matter of policy, I'm a bit reluctant to say "let's add this as an extension because our very important client Chrome is using it". I don't think it's a great way to make decisions. The only reason why I could see us doing it here is because Chrome previously had a free-pass with `__unwrap_iter` and we broke them. But my preference would be to avoid adding those extensions pre-C++20. @rnk can you comment?

Chrome hasn't yet migrated to C++17 yet: https://crbug.com/752720 The major blocker is that nacl compilers are still used somewhere, so I'm pretty sure we are not ready to enable C++20.

In the discussion on the bug with the author of these checked iterators, they seemed OK with relying on implementation details, including re-opening the `std::__1` namespaces with the necessary macros to make the `__unwrap_iter` overload work. I think the optimization only has to work with bundled libc++ version. If that is not in use, the optimization is disabled. I think we might be OK without a properly supported way to do this until we make it to C++20. NaCl is supposed to go away in 2021, so at that point we could probably spring forward and use the officially supported mechanism.

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list