Should we make that a class instead?

Overall we seem to have a happy mix of class and struct, but value_type always seems to be struct so far.

And lazy_split_view::outer-iterator ::value_type uses struct value_type plus private, too.

I think we have only one appearance each of "class outer-iterator" and "struct outer-iterator". Maybe we should make them all structs?

It's not about the outer-iterator; it's about the nested type value_type. Do you have examples where we do class for value_type?

Yes,I know -- as I was saying, all value_types are already structs. But on top of that, we also have some inconsistent use of class/struct for outer-iterator and inner-iterator. All those types feel similar, so I wonder if we should make them all structs, and avoid future uncertainty if and when we get more such types.

I think the better overall approach is to make them all class and drop "private" everywhere: They all start with a bunch of private data members.

But the order-0 local consistency fix (for now) is to add the missing "private" here.

Yes, that's another option. I'm don't have a strong preference, though I think it'd be useful to fix a style.

The fact that the private members appear at the top is another localy style; elsewhere we have private expos-only members at the bottom (so the class key doesn't matter). I'm not sure it's worth mandating a stricter style for the ordering, though.

It is also worth noting that iterator and sentinel are structs in [range.join.with.overview], and then they are later in [range.join.with.iterator] and [range.join.with.sentinel] is defined as a class. Maybe I should open another pull request?

I'd like to see if we can agree on a direction first.

I think we had discussed the ordering of members (private first or public first) in passing at some point, and my general approach is to put private members last (except typedefs). That needs lots of changes in [ranges], so this is not for now. Note also the ongoing discussion in #4702 about styling exposition-only members.

My personal preference for class vs. struct is that struct is used only for aggregates (e.g. the algorithm _result typse); everything else (in particular stuff with private members or any abstraction to speak of) is class.

I still believe that, even absent general consistency, adding "private" here is progress in both correctness of the specification and local consistency, and that's the best we can hope for given the constrained resources we have.

I recorded the issue in #5323.