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.

Sign up for GitHub

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

Jump to bottom

[temp.constr.atomic]/2 Meaning of "the same *expression*" is unclear #2554

Open
CaseyCarter opened this issue Dec 4, 2018 · 5 comments
Open

[temp.constr.atomic]/2 Meaning of "the same *expression*" is unclear #2554

CaseyCarter opened this issue Dec 4, 2018 · 5 comments
Labels
cwg Issue must be reviewed by CWG.

Comments

@CaseyCarter
Copy link
Contributor

[temp.const.atomic]/2 says:

Two atomic constraints are identical if they are formed from the same expression and the targets of the parameter mappings are equivalent according to the rules for expressions described in [temp.over.link].

Not all readers will note that "expression" is italic here, so that it denotes the grammar-term expression, and if they do they may interpret it to mean that "the same expression" means "generated in the same manner from the grammar". Those who don't arrive at this conclusion will likely follow the cross-reference to [temp.over.link] looking for clarification, and will find [temp.over.link]/5:

Two expressions involving template parameters are considered equivalent if two function definitions containing the expressions would satisfy the one-definition rule [basic.def.odr], except that the tokens used to name the template parameters may differ as long as a token used to name a template parameter in one expression is replaced by another token that names the same template parameter in the other expression.

"expressions are equivalent" is pretty close to the phrasing "the same expression", and nothing else in [temp.over.link] tells me what it means for two expressions to be "the same", so paragraph 5 must be why [temp.const.atomic]/2 told me to look at [temp.over.link], right?
@jensmaurer
Copy link
Member

So, should we add "(same sequence of tokens)" after expression?

@CaseyCarter
Copy link
Contributor Author

So, should we add "(same sequence of tokens)" after expression?

The intended meaning is stronger than "same sequence of tokens." Post-P0717, the intent is that two atomic constraints must be generated from the same utterance in order to be equivalent. For example, given:

template<class T> concept C1 = is_same_v<T, int>;
template<class T> concept C2 = is_same_v<T, int>;
void f(C1 auto) {}
void f(C2 auto) {}

the call expression f(42) is ambiguous despite that the two atomic expressions are both spelled is_same_v<T, int> and both have the same parameter mappings. I'm not sure how to phrase "the same utterance" in such a manner that it doesn't suggest that concept definitions in headers are broken when included in multiple TUs.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Dec 20, 2018
@jensmaurer
Copy link
Member

jensmaurer commented Dec 29, 2018 •
edited

So, maybe we should say "the same lexical expression", although I'm still unclear how that translates to linkage across translation units.

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Jun 5, 2019
@zygoloid zygoloid added the cwg Issue must be reviewed by CWG. label Jun 5, 2019
@jensmaurer
Copy link
Member

Editorial meeting: This phrasing is only used for partial ordering, not for redeclarations (which indirectly uses the ODR). We should have a CWG issue to maybe add "... appearing within the same declaration".

@xmh0511
Copy link
Contributor

xmh0511 commented Mar 12, 2021 •
edited

Similar things are

template<class T>
requires (sizeof(T)>0) void fun(T){}  //#1

template<class T>
requires (sizeof(T)>0) && true void fun(T){}  //#2

when partial ordering #1 and #2, although the atomic constraint (sizeof(T)>0) of #1 is literally identical to that of #2 such that it seems to obey "formed from the same appearance of the same expression" and has the same mapping. However, they're not be considered as identity.

@xmh0511 xmh0511 mentioned this issue Mar 28, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
cwg Issue must be reviewed by CWG.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@zygoloid @CaseyCarter @xmh0511 @jensmaurer