Skip to content

Some exposition-only types are not formatted as such in the index #5832

Closed
@jwakely

Description

@jwakely

See chunk_view's inner-iterator and outer-iterator and sentinel:

image

And adjacent_transform_view and adjacent_view's iterator and sentinel:

image

And the index entries for their base() member of various iterator and sentinel types:

image
image

And so on ...

image

image

image

image

image

Activity

jensmaurer

jensmaurer commented on Sep 17, 2022

@jensmaurer
Member

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).

self-assigned this
on Sep 17, 2022
tkoeppe

tkoeppe commented on Sep 24, 2022

@tkoeppe
Contributor

@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

jensmaurer commented on Sep 24, 2022

@jensmaurer
Member

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

W-E-Brown commented on Sep 24, 2022

@W-E-Brown
Contributor
jensmaurer

jensmaurer commented on Sep 24, 2022

@jensmaurer
Member

@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

tkoeppe commented on Sep 24, 2022

@tkoeppe
Contributor

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

jensmaurer commented on Sep 24, 2022

@jensmaurer
Member

We should sort them in the proper alphabetical order; anything else amounts to a special index that nobody wants.

tkoeppe

tkoeppe commented on Sep 24, 2022

@tkoeppe
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    Participants

    @jwakely@W-E-Brown@tkoeppe@jensmaurer

    Issue actions

      Some exposition-only types are not formatted as such in the index · Issue #5832 · cplusplus/draft