[range.split] confuses current and current_

[jwakely]

At http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0896r4.pdf#page=121 we can see that the Effects: of split_view::outer_iterator::operator++ is supposed to use current but in the working draft [range.split.outer] p6 uses current_ which is not the same thing (see [range.split.outer] p1 and #3847).

The same problem exists in [range.split.outer] p8 (comparison with default sentinel), and [range.split.inner] in the synopsis of inner-iterator (definition of operator*).

The original application of P0896R4 (e85af95) was consistent with P0896R4. Then 7989bb4 got rid of current and made current_ stand in for both current_ and parent_->current_. Then 89abe00 (fixing #3562) reintroduced current but didn't restore uses of current, leaving them incorrectly referring to current_.

I think this must be fixed for C++20.

[jwakely]

The real problem here is that current_ and current are almost indistinguishable now that they both use kebab-case. Even when I knew what I was looking for, verifying that I'd fixed it in diffpdf was hard.

[jwakely]

There's also a problem with [range.split.outer] p4 referring to current_ in a function that can be used when Base doesn't satisfy forward_range, i.e. when current_ doesn't exist. That seems like an LWG issue, as it's present in P0896R4.

I think it should say "Initializes parent_­ with i.parent_­ and if Base models forward_range, also initializes current_­ with std​::​move(i.current_­)."

[timsong-cpp]

The real problem here is that current_ and current are almost indistinguishable now that they both use kebab-case. Even when I knew what I was looking for, verifying that I'd fixed it in diffpdf was hard.

Can we editorially rename one of them to something that looks more different?

[jwakely]

I think that would be a good idea. I'll push a second commit to the branch for #3849

[CaseyCarter]

There's also a problem with [range.split.outer] p4 referring to current_ in a function that can be used when Base doesn't satisfy forward_range, i.e. when current_ doesn't exist. That seems like an LWG issue, as it's present in P0896R4.

I think it should say "Initializes parent_­ with i.parent_­ and if Base models forward_range, also initializes current_­ with std​::​move(i.current_­)."

This is subtle: split_view instantiates outer-iterator<true> only when forward_range<V> is true, and we don't care if the body of outer-iterator's conversion constructor template is ill-formed when no one should be calling it.