How to style expos-only members [Was: Restyle expos-only member basic-formatting-string::str] #4702

Activity

1. jensmaurer commented on Jun 17, 2021

   

   jensmaurer

   on Jun 17, 2021

   Last edited by jensmaurer

   Member

   More actions

   The private ranges members are all styled \exposid.

   And, outside of ranges, we have a fair amount of member names not ending in _.

   Personally, I think all exposition-only member names should be italics, and we should find a better / more pronounceable way of creating a new namespace, other than appending _. (In ranges, we occasionally have "current" and "current_", and they mean different things.)
2. jensmaurer

   added

   decision-requiredA decision of the editorial group (or the Project Editor) is required.A decision of the editorial group (or the Project Editor) is required.

   on Jun 17, 2021
3. tkoeppe commented on Jun 17, 2021

   

   tkoeppe

   on Jun 17, 2021

   ContributorAuthor

   More actions

   Do you have a sense of how many non-ranges private members there are?
4. tkoeppe

   changed the title [-]Restyle expos-only member basic-formatting-string::str[/-] [+]How to style expos-only members [Was: Restyle expos-only member basic-formatting-string::str][/+] on Jun 17, 2021
5. tkoeppe commented on Jun 17, 2021

   

   tkoeppe

   on Jun 17, 2021

   ContributorAuthor

   More actions

   Changing the issue to decide the general style first.
6. jensmaurer commented on Jun 17, 2021

   

   jensmaurer

   on Jun 17, 2021

   Member

   More actions

   Do you have a sense of how many non-ranges private members there are?

   Rough estimate, counting the \expos markers (ignoring \exposid):

   $ grep -w expos *.tex | grep -v ranges.tex | wc -l
   275

   In other words, oodles of stuff.
7. tkoeppe commented on Jun 17, 2021

   

   tkoeppe

   on Jun 17, 2021

   ContributorAuthor

   More actions

   OK, thanks. I feel like we're not going to resolve this for this mailing. Maybe for the next pre-meeting mailing!
8. jensmaurer commented on Jun 18, 2021

   

   jensmaurer

   on Jun 18, 2021

   Last edited by jensmaurer

   Member

   More actions

   Editorial meeting 2021-06-18: Consistent, global rule: All private data members have a _ suffix. All exposition-only names (including private data members) are styled with \exposid{...}.

   The presence of the _ suffix is saddening, but we don't have a better idea right now.
9. jensmaurer

   removed

   decision-requiredA decision of the editorial group (or the Project Editor) is required.A decision of the editorial group (or the Project Editor) is required.

   on Jun 18, 2021
10. Dani-Hub commented on Jun 18, 2021

    

    Dani-Hub

    on Jun 18, 2021

    Member

    More actions

    Re @tkoeppe :

    Do you have a sense of how many non-ranges private members there are?

    In N4885 there are 51 occurrences within Clause [ranges], specifically the following ones:
    subrange: 2
    single_view: 1
    iota_view: 2
    iota_view<W, Bound>::iterator: 1
    iota_view<W, Bound>::sentinel: 1
    basic_istream_view: 2
    basic_istream_view<Val, CharT, Traits>::iterator: 1
    ref_view: 1
    filter_view: 2
    filter_view<V, Pred>::iterator: 2
    filter_view<V, Pred>::sentinel: 1
    transform_view: 2
    transform_view<V, F>::iterator: 2
    transform_view<V, F>::sentinel: 1
    take_view: 2
    take_view::sentinel: 1
    take_while_view: 2
    take_while_view<V, Pred>::sentinel: 2
    drop_view: 2
    drop_while_view: 2
    join_view: 2
    join_view::iterator: 3
    join_view::sentinel: 1
    split_view: 3
    split_view<V, Pattern>::outer-iterator: 2
    split_view<V, Pattern>::outer-iterator ::value_type: 1
    split_view<V, Pattern>::inner-iterator: 2
    common_view: 1
    reverse_view: 1
    elements_view: 1
    elements_view<V, N>::iterator: 1
    elements_view<V, N>::sentinel: 1
11. tkoeppe commented on Jun 18, 2021

    

    tkoeppe

    on Jun 18, 2021

    ContributorAuthor

    More actions

    Thanks, Daniel! Unfortunately that seems to mean that we have a lot more "old" private members that we now need to update to the new style :-S
12. JohelEGP commented on Aug 17, 2021

    

    JohelEGP

    on Aug 17, 2021

    Contributor

    More actions

    Editorial meeting 2021-06-18: Consistent, global rule: All private data members have a _ suffix. All exposition-only names (including private data members) are styled with \exposid{...}.

    The presence of the _ suffix is saddening, but we don't have a better idea right now.

    Non-static only?
    

    draft/source/ranges.tex

    Line 5256 in a4e40b0

    static constexpr bool @\exposidnc{ref-is-glvalue}@ = // \expos
13. JohelEGP commented on Aug 17, 2021

    

    JohelEGP

    on Aug 17, 2021

    Contributor

    More actions

    The following Clauses are known to follow the rule (or not):

    • [ranges]
14. W-E-Brown commented on Aug 17, 2021

    

    W-E-Brown

    on Aug 17, 2021

    Contributor

    More actions

    FWIW, I believe this is an incredibly silly de minimis issue to have spent any time on. However, since we have/are, ...

    I find that appending a useless trailing underscore to be an especially egregious waste of time. Moreover, such an emendation sends an entirely unintended message to readers, namely, that the Standard Library recommends the consistent use of trailing underscores for all such exposition-only member names. Since I can find no such policy or recommendation from WG21 (or even from LWG), I (1) object on the grounds that this is not a purely editorial change and (2) request reversion to status quo ante.
15. jensmaurer commented on Aug 17, 2021

    

    jensmaurer

    on Aug 17, 2021

    Member

    More actions

    For [ranges], nothing was changed; the incoming papers generally had italics private data members with trailing underscores. Worse, sometimes we use current_ and current to mean different things (the latter is a meta-macro).

    The most important thing about private data members is that their names are not in any way reserved by the standard library and e.g. a user is allowed to #define a macro with that name. Styling them in an non-utterable way (e.g. italics) seems to help in conveying such a notation. See also our exposition-only concept names.
16. jensmaurer

    added

    decision-requiredA decision of the editorial group (or the Project Editor) is required.A decision of the editorial group (or the Project Editor) is required.

    on Aug 17, 2021
17. jensmaurer

    removed

    decision-requiredA decision of the editorial group (or the Project Editor) is required.A decision of the editorial group (or the Project Editor) is required.

    on Nov 19, 2021
18. tkoeppe commented on Nov 19, 2021

    

    tkoeppe

    on Nov 19, 2021

    ContributorAuthor

    More actions

    @W-E-Brown: The status quo ante is not consistent across the standard, and something we want to improve. We will necessarily have to touch a fair number of places in the standard, no matter which way we go. Marking expos-only members up in the source seems helpful, regardless of how we style them, so that part of the work would need to get done no matter what.

    Have you got any concrete objections to any particular style? Otherwise, we seem to have a strong preference for italics and kebab-case (like all exposition-only names), and a mild preference for the trailing underscore based on partial existing practice.

    I'm inclined to use that throughout unless we have good reasons to prefer something else. But please do note that the ranges library would be ambiguous without the trailing underscore, so alternative proposals would have to provide an alternative disambiguation.
19. tkoeppe commented on Nov 19, 2021

    

    tkoeppe

    on Nov 19, 2021

    ContributorAuthor

    More actions

    Editorial meeting: we would like to continue the direction we decided at the previous meeting, but would like to achieve consensus among the editors.
20. W-E-Brown commented on Nov 20, 2021

    

    W-E-Brown

    on Nov 20, 2021 via email

    Contributor

    More actions

    On Nov 19, 2021, at 12:18 PM, Thomas Köppe ***@***.***> wrote: @W-E-Brown <https://github.com/W-E-Brown>: The status quo ante is not consistent across the standard,

    So? You say that like it's a bad thing.

    and something we want to improve.

    I have yet to hear a cogent reason for this.

    We will necessarily have to touch a fair number of places in the standard, no matter which way we go.

    I don't see why we should bother.

    Marking expos-only members up in the source seems helpful, regardless of how we style them, so that part of the work would need to get done no matter what.

    I've not heard of anyone who has been misled or confused by our current style, so I'm unsure who would find any such adjustment to be "helpful."

    Have you got any concrete objections to any particular style? Otherwise, we seem to have a strong preference for italics and kebab-case (like all exposition-only names), and a mild preference for the trailing underscore based on partial existing practice.

    If this is really worth such relatively large effort for what I see as no gain, I can live with italics. I can even live with kebab-case, if truly necessary. However, a trailing underscore is simply inconsistent with kebab-case. It's not a practice we should be implicitly recommending by imposing everywhere.

    I'm inclined to use that throughout unless we have good reasons to prefer something else.

    No, we need good reasons to change the status quo. I've not seen any in this thread.

    But please do note that the ranges library would be ambiguous without the trailing underscore, so alternative proposals would have to provide an alternative disambiguation.

    Then let's leave the names alone as-is, and be content with (at most) italics to achieve the consistency you seem to find desirable. Or let's find better, underscore-free, names for the ranges library to use. (The only meaningful use of a trailing underscore would have been in names such as kilo_, i.e., in recognized prefixes. But we eschewed trailing underscores there. I just don't understand why we would want to put them in more places where they make no inherent sense.) Sorry, but I still don't find any of this worth even the effort that's already been expended on it. Having multiple ways of expressing valid C++ code is a strength, not a weakness, of the language. Seeking consistency by establishing a convention for such expression seems a waste of our time; I have yet to see a problem here that needs a solution. But if it's still strongly felt that some convention about such names is absolutely needed, then italicize to your hearts' content. But if you additionally want kebab-case, then the trailing underscores (like all underscores) have to go away and the italics alone will have to serve as sufficient disambiguation.

    …

    -- WEB
21. eisenwave

    added a sub-issue on Nov 6, 2025

    • Exposition-Only Members Without \exposid #5940
22. eisenwave

    added

    P2-BugPresentational errors and omissionsPresentational errors and omissions

    on Nov 6, 2025
23. eisenwave commented on Nov 6, 2025

    

    eisenwave

    on Nov 6, 2025

    Member

    More actions

    Marking this P2 because there now is an objectively correct style for private/exposition-only members, and this issue relates to violations of that style.