Consistent Function Label Naming for Sections

[Benio101]

Make [print.fun] consistent with other label names.

🔗 https://isocpp.org/files/papers/P3539R1.pdf

[Benio101]

If I should make a P version of paper instead of github PR, please, let me know.

[jensmaurer]

Label naming is entirely editorial, although we tend to avoid changing label names without consulting with CWG or LWG. Please don't spend paper numbers on such matters unless directed to do so by the Project Editor. You can easily present the consistency argument in the pull request description inline instead of requiring me to click on a PDF link.

@jwakely , any concerns about the label rename here?

[jensmaurer]

(And now that you've invested in a paper number, do make sure it appears as a P paper in the next mailing; allocating paper numbers without publishing the corresponding paper isn't helpful either.)

[jensmaurer]

Please add a \movedxref to xrefdelta.tex:

2024-12-12T13:38:09.4479369Z incorrect entries in xrefdelta.tex:
2024-12-12T13:38:09.4494751Z missing print.fun

(output of checking is accessible via "view raw logs")

[jensmaurer]

Thanks. Now, please read https://github.com/cplusplus/draft/wiki/Commit-message-format

squash your commits, adjust the commit message, and force-push.

[jwakely]

We already had this stable name in C++23. Is being consistent with other stable names more important than being consistent with C++23?

In my opinion, it's not. The names are pretty much arbitrary and their main purpose is a name that always refers to the same subclause even if it's renumbered.

[Benio101]

Continuation: #7495.

[tkoeppe]

I agree, let's not change things just for the sake of it. The stable labels serve a purpose. We already have pushback against the somewhat frivolous changes of stmt.stmt, because they interrupt established workflows of people for few good reasons, and it's a trade-off. A sufficiently large group felt that the damage done by the existence of stmt.stmt to our perceived collective ego outweighs the disruption of people who have been working with the standard for a long time, but this is not a decision we make lightly and that needs rationale and consensus.

[jwakely]

There is absolutely no reason why two completely unrelated subclauses such as [any.general] and [basic.scope.general] need to be "consistent". Their purpose is to be a stable name that refers to the relevant subclause, not to follow a non-existent policy on consistent naming.

[Benio101]

There is absolutely no reason why two completely unrelated subclauses such as [any.general] and [basic.scope.general] need to be "consistent". Their purpose is to be a stable name that refers to the relevant subclause, not to follow a non-existent policy on consistent naming.

While I completelly disagree, neither [any.general] nor [basic.scope.general] seems to be related to this proposal at all.

[CaseyCarter]

A sufficiently large group felt that the damage done by the existence of stmt.stmt to our perceived collective ego outweighs the disruption of people who have been working with the standard for a long time, but this is not a decision we make lightly and that needs rationale and consensus.

So, we're changing it to [stmt.stmt.stmt]?

[tkoeppe]

So, we're changing it to [stmt.stmt.stmt]?

Precisely: that way, both the familiar "stmt.stmt" and the proposed new "stmt" become greppable.