Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce term.* labels for [basic.types.general] terms #5104

Merged
merged 10 commits into from Feb 22, 2022

Conversation

jensmaurer
Copy link
Member

For ease of review, these are all separate commits.
Feel free to squash on merge.

Fixes #4630

Copy link
Contributor

@JohelEGP JohelEGP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines says "create a \label{term.this.name} at the start of the paragraph defining the term". Perhaps it should say "sentence" rather than "paragraph".

61245eb starts with [std} rather than [std].

@jensmaurer
Copy link
Member Author

@JohelEGP , fixed both issues.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 14, 2022

@zygoloid, @opensdh: this looks very nice, but I'd welcome some more Core eyes on those new terms.

@JohelEGP
Copy link
Contributor

No new terms were introduced.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 14, 2022

(I mean the internal labelling of terms. The labelling is new, I suppose, not the terms.)

Copy link
Contributor

@opensdh opensdh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like this is an opportunity to do something like \impldef, where instead of

shall be a foo type\iref{term.foo.type}.

we could write

shall be a \tref{foo.type}.

Of course, we sometimes use just the adjective alone (which is known by \defnadjx at least), so we might want \adjref as well.

@jensmaurer
Copy link
Member Author

In order to make \tref workable, we need LaTeX foo to replace the periods with spaces (or the other way round).

@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 14, 2022

(Tangent: if we had a text replacement system for LaTeX, I would also have a nice improvement for the unicode-smallcaps formatting -- I would like to format numerals and letters differently, but I don't know how to do that as a macro.)

@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 14, 2022

Why can't \tref{foo.type} work like savebox where it stored the actual content somewhere else?

@jensmaurer
Copy link
Member Author

jensmaurer commented Jan 14, 2022

I guess there are not sufficiently many \saveboxes; I thought that's a quite finite resource.
Anyway, the definition of the term would need to translate space to period, which is approximately the same problem.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 15, 2022

We could use a custom label to store terms. For example:

\documentclass[a4paper,11pt]{article}

\makeatletter
\newcommand{\termdef}[2]{%
\protected@write \@auxout {}{\string \newlabel {#1}{{#2}{}}}#2}
\makeatother

\begin{document}
The \ref{term.dcl.spec} shall not be empty.
A \termdef{term.dcl.spec}{decl-specifier} is a thing you can use.
\end{document}

This uses the aux file as storage and requires multiple passes etc etc.

@jensmaurer
Copy link
Member Author

jensmaurer commented Jan 15, 2022

@tkoeppe, that's not substantially different from my \label{term...} approach, which requires less internal knowledge about the structure of the .aux files.

We'd reap real benefits if we could make \defn (etc) auto-generate a label that could then be used via \termref or similar, using human-readable space-separated terms in both cases, and internally mapping to a dotted form with a "term." prefix.

Ah, looks like the xstring package does exactly that: https://tex.stackexchange.com/questions/36266/replacing-characters-in-argument-strings

@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 15, 2022

@jensmaurer, sort of, but what I'm proposing is to just explicitly spell out both the label and the actual term, rather than deriving one from the other. Not only does that require less implementation magic, but it also makes it possible to change the term without changing the label, etc. And the auxfile labelling mechanism is pretty well-established and tractable.

We could make a new command to replace \ref, e.g. \termref, to make the use clearer at the callsite.

@jensmaurer
Copy link
Member Author

@tkoeppe , thanks for your thoughts. See #5210 for an approach that introduces term.* labels automatically.

Note that for each \defn (i.e. each term definition), we produce three things:

  • text to be shown in the document
  • an index entry
  • (new) a label

We need macros so that the common case is easy, but (if need be) all three items must be influenceable independently.
For now, #5210 auto-generates labels from (the indexing portion of) \defn, \defnx, \defnadj, \defnadjx, but for index entries using special characters such as ! or @ to fine-tune the indexing, the resulting term.* label is ugly.
That doesn't prevent us from introducing a nice-looking term.* label in the vicinity, though.

In my view, \termref should show both the term and the cross-reference to where it is defined, e.g. "odr-use (6.2)", while naming the term only once.

And just to point out: Memoir creates .aux entries like this for \label:

\newlabel{term.piecewise.construction}{{\M@TitleReference {20.4.2}{Class template \texttt {pair}}}{579}{Class template \tcode {pair}}{lstlisting.20.-1376}{}}

@jensmaurer
Copy link
Member Author

Automating the term.* definitions does detect duplicate term definitions quite nicely; see #5210

@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Feb 21, 2022
@jensmaurer jensmaurer removed the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Feb 21, 2022
@tkoeppe tkoeppe merged commit e6c0390 into cplusplus:main Feb 22, 2022
@jensmaurer jensmaurer deleted the c57 branch February 22, 2022 12:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Imprecise cross-references for "trivially copyable type"
5 participants