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

"shall not participate in overload resolution unless" considered not not harmful #86

Closed
StephanTLavavej opened this issue Apr 23, 2013 · 5 comments
Closed

"shall not participate in overload resolution unless" considered not not harmful #86

StephanTLavavej opened this issue Apr 23, 2013 · 5 comments
Assignees
@jyasskin
Labels
lwg Issue must be reviewed by LWG.

Comments

@StephanTLavavej
Copy link
Contributor

Search for "shall not participate". There are around 40 occurrences of the form "X shall not participate in overload resolution unless Y". This is unnecessarily confusing. "X shall participate in overload resolution if and only if Y" would be clearer, and as a bonus, it would mirror how enable_if is used.

There are only a few occurrences that aren't exactly of this form which will need slightly less mechanical reworking:

  • 20.3.2 [pairs.pair]/9 is unnecessarily phrased differently from the other pair constraints: "Remarks: If U is not implicitly convertible to first_type or V is not implicitly convertible to second_type this constructor shall not participate in overload resolution."
  • 23.6.3.3 [queue.cons.alloc]/1, 23.6.4.2 [priqueue.cons.alloc]/1, and 23.6.5.4 [stack.cons.alloc]/1 say: "If uses_allocator<container_type, Alloc>::value is false the constructors in this subclause shall not participate in overload resolution."
  • 23.2.3 [sequence.reqmts]/14 says: "If the constructor [...] is called with a type InputIterator that does not qualify as an input iterator, then the constructor shall not participate in overload resolution." and "If the member functions of the forms: [...] are called with a type InputIterator that does not qualify as an input iterator, then these functions shall not participate in overload resolution."
  • 26.5.3 [rand.eng]/6 says: "if the constructor [...] is called with a type Sseq that does not qualify as a seed sequence, then this constructor shall not participate in overload resolution;" and "if the member function [...] is called with a type Sseq that does not qualify as a seed sequence, then this function shall not participate in overload resolution."
  • 30.6.8 [futures.async]/8 says: "Remarks: The first signature shall not participate in overload resolution if decay::type is std::launch."
@jwakely
Copy link
Member

jwakely commented Apr 23, 2013

The final one was already removed by #39

@sdutoit
Copy link
Contributor

sdutoit commented May 16, 2013

After editing in some more text with this double negative (specifically, the "...unless" form) in it, I tend not to disagree with you.

Personally, I like "X shall only participate in overload resolution if Y".

@StephanTLavavej
Copy link
Contributor Author

"X shall only participate in overload resolution if Y" is problematic because "only" binds very tightly in English.

For example, "Only I talk about C++" (i.e. nobody else talks about C++), "I only talk about C++" (i.e. I don't do anything else with C++, like write it), and "I talk about only C++" (i.e. I don't talk about Fortran, or anything else) are all different sentences.

I know it came up on the reflector and I forget what the consensus was, but it'd be nice to define "iff" so we could use it throughout the Standard.

@FrankHB
Copy link
Contributor

FrankHB commented May 16, 2013

+1 for "iff".

@zygoloid zygoloid added the lwg label Jun 18, 2014
@zygoloid
Copy link
Member

This is LWG2292.

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

@jyasskin jyasskin

Labels
lwg Issue must be reviewed by LWG.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@jyasskin @zygoloid @sdutoit @jwakely @FrankHB @StephanTLavavej