[basic.link], [expr.ref] Harmonize font for tuple representing direct base class relationship#8333
Conversation
| a member of \tcode{T1} or | ||
| a direct base class relationship $(\tcode{T1}, \tcode{B})$. | ||
| a member of $\mathit{T1}$ or | ||
| a direct base class relationship $(\mathit{T1}, B)$. |
There was a problem hiding this comment.
I'd suggest to leave the code font for T1 alone and say in the last line:
"or a direct base class relationship
That seems least awkward from a "types are code font" perspective.
@tkoeppe , what do you think?
There was a problem hiding this comment.
To be fair, we have some other places where types are turned into math font because
I don't really care either way; both options suck equally.
There was a problem hiding this comment.
Hm, this is tricky, and I don't think the NB comment is well-formed. It is simply the case that we sometimes use maths variables for abstract placeholders (like in [basic.link]) and sometimes we use code font (like in [expr.ref]). It's not the property of "the tuple representing direct base class relationships" to prescribe how the arguments of that relationship are to be formatted. We use whatever arguments we have. Unfortunately we are currently using different styles in different places, but it's not trivial or obvious to change any or all of those.
I think we can take the first part of this change, since it's certainly fine to use maths variables for the purpose of definining the relationship, and that would be consistent with how we define that big T, N, A, ... tuple just below.
But the second change I would just drop. The current style used in [expr.ref] is reasonable in context, and I don't see a need to change it (nor any benefit in doing so).
There was a problem hiding this comment.
I.e. we can say "accepted with modifications".
… base class relationship Fixes NB US 1-405 (C++26 CD).
|
Great, thanks! |
Fixes NB US 1-405 (C++26 CD).
Fixes https://github.com/cplusplus/nbballot/issues/586.
This only changes the spellings in core wording, in [basic.link] and [expr.ref].
@jensmaurer requested in https://github.com/cplusplus/nbballot/issues/586#issuecomment-3363206752 that code font should not be used. That seems to be the path of least resistance, although, to be fair, a direct base class relationship is always between two types, and we tend to use code font for types. Using math font also leads to a quirky change in [expr.ref] where
\tcode{T1}becomes$\mathit{T1}$.In [meta.reflection], the wording uses
$(D, B)$consistently everywhere. This spelling also appears once in https://eel.is/c++draft/expr.ref#8.6. I think we should aim to spell both the base class relationship and the data member description tuples entirely in math context, including the parentheses, which is already the most common form.Maybe we could revisit these font choices later, but for now, let's just make it consistent with a fairly small change, and move on.