Is [flat.map] right? flat_map does have a compare non-static data member. If you expand the context of the first change towards the top, you can even see

Is [flat.map] right? flat_map does have a compare non-static data member.

Oh, bother. This whole thing might just be a subset of the "need to \exposid more things" issue, then. I think this PR is still a minor improvement in clarity, but maybe it's not a mistake as-written. Feel free to close this PR if that's the general consensus.

I also just noticed that https://eel.is/c++draft/flat.map#overview-10 arguably should say "range that is not sorted with respect to value_comp()" instead of "with respect to key_­comp()", but don't plan to submit a PR for that.

I also just noticed that https://eel.is/c++draft/flat.map#overview-10 arguably should say "range that is not sorted with respect to value_comp()" instead of "with respect to key_­comp()", but don't plan to submit a PR for that.

IIRC, only the keys are required to be sorted.

I also just noticed that https://eel.is/c++draft/flat.map#overview-10 arguably should say "range that is not sorted with respect to value_comp()" instead of "with respect to key_­comp()", but don't plan to submit a PR for that.

IIRC, only the keys are required to be sorted.

Yes, but in

    template<class InputIterator>
      flat_map(sorted_unique_t s, InputIterator first, InputIterator last,
               const key_compare& comp = key_compare())

the range expressed by [first, last) is a range of value_type (i.e. pair<Key,T>) that must be sorted w.r.t. value_comp(). key_comp() will be something like less<Key>, which doesn't take pairs at all. But I think you've just found another typo, namely "...a container, containers, or range that is not sorted..." I don't think there's any situation where more than one container needs to be sorted by anything. Anyway, my overall sense is that this intro wording is vague and messy and that's exactly why I'm not going to tackle submitting a PR for it. :)

Orthogonally yet again, I notice that the from_range_t overloads do not support e.g. mySortedVector | views::unique | ranges::to<flat_set<int>>(sorted_unique). But I assume that's at least semi-intentional and thus LEWG territory.