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

[meta, thread] Add/amend references to func.require, func.invoke #5859

Closed
wants to merge 11 commits into from

Conversation

ecatmur
Copy link

@ecatmur ecatmur commented Sep 20, 2022

In particular, not knowing where to find the definition of INVOKE (it's in the library index, but not the main index) is highly frustrating when reading is_invocable et al.

Corrected references in [thread] and added some more for completeness.

There's a bunch of uses of 'invoke' in [algorithm] and [ranges] that could also have references added, but that feels less necessary.

source/threads.tex Outdated Show resolved Hide resolved
source/threads.tex Outdated Show resolved Hide resolved
source/threads.tex Outdated Show resolved Hide resolved
Copy link
Member

@jensmaurer jensmaurer left a comment

Choose a reason for hiding this comment

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

Hm... Maybe we should add INVOKE to the main index instead.
On the other hand, INVOKE is used in a rather scattered way, so just adding cross-references seems plausible.

@tkoeppe?

@@ -1669,7 +1669,7 @@
Initializes \tcode{ssource}.
The new thread of execution executes
\begin{codeblock}
invoke(auto(std::forward<F>(f)), get_stop_token(),
invoke(auto(std::forward<F>(f)), get_stop_token(), // see \ref{func.invoke}, \ref{thread.jthread.stop}
Copy link
Member

Choose a reason for hiding this comment

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

We should not add a cross-reference for get_stop_token; it's right in this (or the next) section.

Copy link
Contributor

@tkoeppe tkoeppe Sep 24, 2022

Choose a reason for hiding this comment

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

Agreed.

It's a bit annoying that the comment is not a great place for the cross-reference, since it's not clear which bit of the code it refers to (forward? auto? invoke?). I wonder if an explicit note (e.g. "invoke is defined in \ref(...)") would be clearer -- thoughts?

Copy link
Author

Choose a reason for hiding this comment

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

trying "for invoke, see \ref{...}", does that look OK?

@AlisdairM
Copy link
Contributor

AlisdairM commented Sep 21, 2022

Personal experience: I often look up INVOKE based on conversations outside the standard. I always start with the main index, thinking it is not an identifier in the library, and fall back on the index of library names as my second choice. Hence, I advocate adding/moving to the main index.

Note that this should have no bearing on whether we add internal cross-references as well!

@tkoeppe
Copy link
Contributor

tkoeppe commented Sep 24, 2022

Even if we do add cross-references, I don't think we need to add them repeatedly within the same subclause -- just the first time it comes up? E.g. we do this in [basic.extended.fp], where we say "extended floating-point type" many times, but only the first mention gets a cross-reference.

ecatmur and others added 8 commits September 25, 2022 17:10
from [meta] and [threads]

In particular, not knowing where to find the definition of *INVOKE* (it's in the library index, but not the main index) is highly frustrating when reading is_invocable et al.

Corrected references in [threads] and added some more for completeness.

There's a bunch of uses of 'invoke' in [algorithm] and [ranges] that could also have references added, but that feels less necessary.
Co-authored-by: Johel Ernesto Guerrero Peña <johelegp@gmail.com>
Co-authored-by: Johel Ernesto Guerrero Peña <johelegp@gmail.com>
source/threads.tex Outdated Show resolved Hide resolved
Co-authored-by: Johel Ernesto Guerrero Peña <johelegp@gmail.com>
@JohelEGP
Copy link
Contributor

I think this should be approved.
1664126284

@tkoeppe
Copy link
Contributor

tkoeppe commented Nov 7, 2022

Squashed into ef7d0e2, e662693 -- thank you!

@tkoeppe tkoeppe closed this Nov 7, 2022
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.

None yet

5 participants