Some exposition-only types are not formatted as such in the index #5832
Comments
|
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). |
|
@jensmaurer What about exposition-only members such as And namespace-scope variable templates such as |
|
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? |
|
We should sort them in the proper alphabetical order; anything else amounts to a special index that nobody wants. |
|
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? |
See
chunk_view's inner-iterator and outer-iterator and sentinel:And adjacent_transform_view and adjacent_view's iterator and sentinel:
And the index entries for their
base()member of various iterator and sentinel types:And so on ...
The text was updated successfully, but these errors were encountered: