You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All kebab-case names should be in exposition-italics. If you notice any that aren't, we should fix them. But those exposition-only names cannot ever be called by users, so they shouldn't appear in the index of library names.
On Sep 24, 2022, at 2:07 PM, Jens Maurer ***@***.***> wrote:
All kebab-case names should be in exposition-italics. If you notice any that aren't, we should fix them. But those exposition-only names cannot ever be called by users, so they shouldn't appear in the index of library names.
I respectfully disagree with this latter opinion, as the library index is the first place I would seek to find such names. I wouldn't mind having these names in the general index as well, but it seems to me that a library-only artifact that, in fact, could be implemented as specified, ought be findable via a library-only index.
On further reflection, I would not object to such names' inclusion in a more general index, as well, but that wouldn't be the first place I'd look. Whether an entity is callable seems not the best criterion, in my opinion, on which to base an indexing decision.
I briefly contemplated the notion of a separate index of exposition-only names, but I find myself lukewarm as to that idea. Nonetheless, I would find that an acceptable compromise although it wouldn't be my first choice.
@tkoeppe, we need a new issue here that we can mark "decision-required". I do agree the exposition-only names should be in some index (or several?); the question is which one. I'm not strongly opposed to the library names index if we add some intro paragraph explaining the typeface.
We can open such an issue, but for now we have four straggling exposition-only names that remain in the library index, in the wrong place (namely right at the start), which doesn't seem all that useful, either.
Maybe we could put all the exposition-only names into the existing library index, but into a separate section?
The library index also serves as a list of reserved names (e.g. for the purpose of defining macros) so maybe there's some value in not "polluting" that list with names that don't affect actual programs, but only exist for the purpose of specification?
Activity
jensmaurer commentedon Sep 17, 2022
We don't want to index exposition-only names at all, I think, because those are not names that could appear in user programs.
So, exposition-only member functions should not be indexed.
For exposition-only classes, we do want to index them, if/when they contain user-visible member functions (e.g. operators in case of views).
tkoeppe commentedon Sep 24, 2022
@jensmaurer What about exposition-only members such as
move_only_function::is-callable-from
?And namespace-scope variable templates such as
is-vector-bool-reference
?jensmaurer commentedon Sep 24, 2022
All kebab-case names should be in exposition-italics. If you notice any that aren't, we should fix them. But those exposition-only names cannot ever be called by users, so they shouldn't appear in the index of library names.
W-E-Brown commentedon Sep 24, 2022
jensmaurer commentedon Sep 24, 2022
@tkoeppe, we need a new issue here that we can mark "decision-required". I do agree the exposition-only names should be in some index (or several?); the question is which one. I'm not strongly opposed to the library names index if we add some intro paragraph explaining the typeface.
tkoeppe commentedon Sep 24, 2022
We can open such an issue, but for now we have four straggling exposition-only names that remain in the library index, in the wrong place (namely right at the start), which doesn't seem all that useful, either.
Maybe we could put all the exposition-only names into the existing library index, but into a separate section?
jensmaurer commentedon Sep 24, 2022
We should sort them in the proper alphabetical order; anything else amounts to a special index that nobody wants.
tkoeppe commentedon Sep 24, 2022
The library index also serves as a list of reserved names (e.g. for the purpose of defining macros) so maybe there's some value in not "polluting" that list with names that don't affect actual programs, but only exist for the purpose of specification?