Is specifying the complicated return type necessary here (i.e., could this function get away with just auto)?

Nit: a few of these functions should be formatted so that the opening brace is on the same line as the function name.

Nit: can __bs be a little more descriptive?

Why is this implementation different from the overload above (and from the Standard)?

Hmm, is this equivalent to the Standard's wording?

The exception specification is equivalent to the logical AND of the following expressions:

noexcept(ranges::iter_swap(std::get<i>(l.current_), std::get<i>(r.current_)))

for every integer  `0 ≤ i < sizeof...(Views)`.

Optional: since this pattern is used twice (here and in __iterator), consider splitting it into a function (e.g. __tuple_zip_any_of).

Hmm, looking at the latest draft, it says

Given a pack of subexpressions `Es...`, the expression `views​::​zip(Es...)` is expression-equivalent to
<...>
(2.2) otherwise, `zip_­view<views​::​all_­t<decltype((Es))>...>(Es...)`.

This does not appear equivalent (missing views::all_t).

Is a case where neither of the overloads is available? (i.e., is it possible for a type to not satisfy range<const Views> && ... while still satisfying the class constraints?) If yes, can you add a compile-time test to check that case?

Nit: s/borrwed/borrowed/.

This file should also check piping zip. Can you take a look at test/std/ranges/range.adaptors/range.filter/adaptor.pass.cpp and implement the relevant checks from that test here?

Also, I'd rename it into adaptor.pass.cpp for consistency with other views.

Consider renaming to NoDefaultCtrView.

Hmm, I don't see a constraint on either the default constructor or the class itself that requires Views to be default-constructible. I'm probably missing it -- can you please check?

Wouldn't std::convertible_to work?

Seems like this could be UB? Consider making moves a one-element array.

Nit: s/stack/the local variable/ -- the parameter is also on the stack, after all.

Optional: these checks are so similar that they could be extracted into a helper function that takes two template arguments for the view types to create. But the current state is also fine since there are only 3 similar cases (extraction would allow you to add more cases easily if you'd like).

Shouldn't these check v.end() rather than v.begin()? (applies throughout)

Please specify the constraints (I'd be okay with just writing something like:

// All the arithmetic operators have the constraint `requires all-random-access<Const, Views...>;`,
// except `operator-` which has the constraint `requires (sized_­sentinel_­for<iterator_t<maybe-const<Const, Views>>,
                                   iterator_t<maybe-const<Const, Views>>> && ...);`

(of course, double check the above for correctness if you decide to use it)

Nit: this blank line seems extraneous.

These checks seem unnecessary -- it's already checked at runtime above (applies below as well).

Nit: s/range/the ranges/ (here and below).

Question: what does "default" and "non-default" mean in the context of these classes?

Similar question to zip_view's default constructor -- where does this constraint come from?

Nit: can this be = zip_iter<Default> (or just use zip_iter<Default> without an alias)?

Missing requires clause.

Can you also check the case when the conversion is from non-const to const, but (!convertible_­to<iterator_t<Views>, iterator_t<maybe-const<Const, Views>>> && ...)?

Nit: this synopsis is missing the requires clause.

Optional: probably overkill, but it could also check the post-decrement version (using "or").

What's the reason to not go from the end like in the previous test case?

Nit: s/forword/forward/.

Missing the noexcept clause (here and in iter_swap test).

Wouldn't it be easier to just create a local variable and use it here instead of declval?

Note: there's an ASSERT_NOT_NOEXCEPT macro, but using it is completely optional. I don't really have a preference.

iter_move must call ranges::iter_move, which is a customization point object. Can you please check that your specialization of iter_move is found via ADL even if it's in a different namespace (see some other views, e.g. lazy_split_view, for an example)?

Check the inverse case as well? (i.e., !noexcept)

Same comment re. ADL as iter_move.

Nit: use PascalCase for consistency with names of the other classes in this file?

Can you also test the case when iterator_concept is bidirectional_iterator_tag?

Note: in synopsis, there is no reason to mangle names -- i.e., please s/__n/n/. Can you please check other test files' synopses for similar issues?

Please check the constraint as well.

Nit: unnecessary blank line.

Nit: s/static_assert/static_asserts/ (or static assertions).

Can you use the output iterator from test_iterators.h instead?

Nit: s/Converitble/Convertible/.

Nit: weird formatting.

Question: isn't this checked by the comparisons above?

Please add empty lines between the test cases and short comment describing what each test case does.

Nit: weird formatting for these concepts (clang-format doesn't support concepts properly, IIRC).

Please add short comments describing what each test case does.

Same nit re. empty lines and comments for each test case. Looks like it applies throughout the patch.

Similar comments to join_view -- BufferView would be a more appropriate name, see if you can use std::span instead.

Good idea. We have some existing test code that we could simplify this way.

Nit: the opening brace goes on the same line as the function name (applies throughout the file, and possibly in other files as well).

Nit: extra semicolon.

I mean, could you rely on CTAD? To be clear, it's just a question -- perhaps CTAD won't work here.

Perhaps we should test that the iterator is reassignable/destroyable, but perhaps it's overkill. Let's check with Louis @ldionne.

I fully agree, being able to use clang-format would be great (though note that it's not fully straightforward on our code base).

It's a little easier to compare when things are close to the Standard text (unless, of course, there's a reason to diverge), but it's a really small thing -- we can keep as is.

Very optional: this comment can fit in one line.

Sounds reasonable, but I'd ask Louis @ldionne to double-check just in case.

A word seems to be missing -- "should _be_ at the begin position"?

Ah, makes sense, never mind.

Because it's not obvious, can you please add this as a comment?

Ah, right (you might also want to check that the default constructor is explicit, though it starts going into the overkill territory).

Thanks for pointing it out -- it made me find this post that quotes the relevant part of the Standard (updated to the current draft):

When an expression J that has integral type is added to... an expression P of pointer type...

<...>

(4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]),70 the expressions P + J and J + P... point to the (possibly-hypothetical) array element i + j of x if 0 ≤ i+j ≤ n...

<...>

70. As specified in [basic.compound], an object that is not an array element is considered to belong to a single-element array for this purpose and a pointer past the last element of an array of n elements is considered to be equivalent to a pointer to a hypothetical array element n for this purpose.

(By the way, ignoring optional comments is fine -- that's why they're optional, after all -- but if you decide not to implement an optional suggestion, can you please add a comment to that effect? This would help me understand whether this is something you plan to come back to later or something you decided to push back on. Once again, pushing back is fine -- I just want to make sure I understand the state of the patch, i.e. whether all comments are addressed one way or the other)

Nit: I think the meaning would be a little more obvious if s/which/which instead/. (I know the current text is my suggestion)

Nit: with the new sentence structure, I think this should be sentinels.

Some nits:

• s/as/in;
• consider in the way defined by the standard;
• I think there should be no comma between defined and but;
• consider s/but/but instead/;
• (ultranit) please add a full stop at the end of the sentence.

Nit: s/Opeartors/Operators/.

Should it also call inequalityOperatorsDoNotExistTest?

Is it possible to also add a static_assert to show that the convertible_­to constraint is not satisfied in this case? (Only if it's straightforward, it's basically to "test the test" and to make it a little more obvious what exactly it's testing)

Thanks for adding the test! Relying implicitly on the include order would be too subtle, IMO.

Nit: s/shoud/should/.

Nit: probably s/ranges/views/? That's the name of the template argument / constructor argument.

Nit: s/multiple/of multiple (here and below).

Thanks for adding all the comments! Much easier to skim through now.

Optional nit: s/minus/subtract/.