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

Qualify all calls to std::get #5556

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

cor3ntin
Copy link
Contributor

@cor3ntin cor3ntin commented Jul 8, 2022

There have been some discussions and confusion about whether std::get
can be specialized for user types.
It can't, it's not a customization point and the standard always
calls it qualified. As the issue has come around a few times,
the standard should make it clear that this calls is always
qualified, like it does for std::move and std::forward.

@cor3ntin
Copy link
Contributor Author

cor3ntin commented Jul 8, 2022

@jwakely Does this needs an LWG issue or is it sufficiently editorial?

source/declarations.tex Outdated Show resolved Hide resolved
source/ranges.tex Outdated Show resolved Hide resolved
source/utilities.tex Outdated Show resolved Hide resolved
There have been some discussions and confusion about whether `std::get`
can be specialized for user types.
It can't, it's not a customization point and the standard always
calls it qualified. As the issue has come around a few times,
the standard should make it clear that this calls is always
qualified, like it does for std::move and std::forward.
@jensmaurer
Copy link
Member

Please review the failed checks: there are now some overfull \hboxes.

@jwakely , do you want to make this happen?

@jwakely
Copy link
Member

jwakely commented Jul 8, 2022

I think Corentin's rationale is sound. I think some people might object on the basis that they want to see us not qualifying move and forward, so this goes in the wrong direction. But since we're not actually proposing to stop qualifying them at this time, I think adding get to the set makes sense. Let's give this five minutes in an LWG telecon and maybe discuss on the LWG reflector. If nobody has any reasonable objections, we should go ahead as an editorial change.

@JohelEGP
Copy link
Contributor

JohelEGP commented Jul 8, 2022

\\ is novel. It seems to be a line break, rather than a hint (as with non-novel ways to fix an overfull \hbox), so the resulting text isn't justified:
1657307279
1657307322
1657307352
1657307367
And the last one ate the \ in \tcode{.

@CaseyCarter
Copy link
Contributor

I think some people might object on the basis that they want to see us not qualifying move and forward, so this goes in the wrong direction.

"Some people" here, objecting as expected =) I'm not opposed to explicitly qualifying names, I'm opposed to explicitly qualifying some names explicitly while at the same time explicitly qualifying other names implicitly via blanket wording except for some other names that are implicitly not explicitly qualified so as to enable ADL. It's become nearly impossible to explain to people outside LWG (let alone outside WG21) when and why we qualify names in the library spec. We need to have fewer rules with no exceptions unless our intent is truly that only implementors who attend LWG need to understand.

@jensmaurer jensmaurer added the lwg Issue must be reviewed by LWG. label Jul 15, 2022
@jensmaurer
Copy link
Member

@cor3ntin , please address @JohelEGP 's comments.
In general, we don't want to break lines super-early; it's even ok to have hyphenation in C++ code snippets. (Breaking after an opn ( is fine, too.)

@jensmaurer jensmaurer added the changes requested Changes to the wording or approach have been requested and not yet applied. label Jul 15, 2022
@cor3ntin
Copy link
Contributor Author

@jensmaurer I was planning to wait for lwg to set a direction, but also, I'm afraid my latex is failing me - I tried and looked for different approaches and couldn't find how the standard deals with that in general) What solution do you recommend?

@JohelEGP
Copy link
Contributor

how the standard deals with that in general

I know of \-, \brk{}, and turning a \tcode into a codeblock environment.

@JohelEGP
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changes requested Changes to the wording or approach have been requested and not yet applied. lwg Issue must be reviewed by LWG. needs rebase The pull request needs a git rebase to resolve merge conflicts.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants