See #5812.

This is repeating the same mistakes explained at #5696 (comment). This means that there are many more places left to mark with \exposid than those you've actually marked.

I think we agree we have an inconsistency, but my preference would be to address all of [containers] and add \exposid and kebab-case throughout.

However, we should confirm with @tkoeppe and the rest of the editorial group whether we really want that, and then we should strive for a comprehensive patch.

I think we agree we have an inconsistency, but my preference would be to address all of [containers]

Before making this PR, I wasn't aware of the apparent controversy here. :) Perhaps there's more to do after this; but the question for me is simply, does anyone claim there's less to do? Right now the formatting is in a "very" inconsistent state, where if you scroll down through https://eel.is/c++draft/flat.map.defn you'll see : c(), compare(comp) with the names upright (like in https://eel.is/c++draft/priority.queue , although to be fair https://eel.is/c++draft/priority.queue doesn't use member-initializer-lists), and if you scroll down through https://eel.is/c++draft/flat.set.defn : c(), compare(comp) with the names italicized. This suggests there is a difference between how the name is used in flat_set versus how it's used in priority_queue and flat_map. But that suggestion is misleading.

I can certainly imagine that people want to italicize other expos-only members, like key_equiv and value_compare.comp and so on; I have no particular opinion on those personally because AFAICT the current state of the world there isn't currently inconsistent with anything. So IMHO the larger discussion needn't block this small consistency patch.

Editorial meeting comment: we would like a consistent style across all four new "flat" container adaptors: exposition-only members should be marked up with \exposid, and their names are not required to end in underscores. (I believe that none of them currently do, so no change is needed.) We should only focus on those four class templates here, and leave considerations about the rest of the standard for the future.

For tangential context: the discussion on how to name exposition-only members is in #4702.

Editorial meeting comment: we would like a consistent style across all four new "flat" container adaptors: exposition-only members should be marked up with \exposid, and their names are not required to end in underscores. (I believe that none of them currently do, so no change is needed.) We should only focus on those four class templates here, and leave considerations about the rest of the standard for the future.

FWIW, I'm happy to do the grunt work and update this PR if it's helpful, but I wasn't in that meeting and therefore don't really understand what was agreed upon. Would the non-obvious part be like this?

    containers \exposid{c};               // \expos
    key_compare \exposid{compare};        // \expos

    struct \exposid{key-equiv} {  // \expos
      \exposid{key-equiv}(key_compare c) : comp(c) { }
      bool operator()(const_reference x, const_reference y) const {
        return !comp(x.first, y.first) && !comp(y.first, x.first);
      }
      key_compare comp;
    };

AFAICT the name of key_compare comp (which matters only w.r.t macro.names/1), and the fact that it's captured by value (yikes), are not exposition-only, under the current wording. I also wish that exposition-only one-arg ctor were explicit.

Abandoning.