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

[func.require] Unclear use of "shall" LWG4007 #6640

Closed
frederick-vs-ja opened this issue Nov 2, 2023 · 6 comments
Closed

[func.require] Unclear use of "shall" LWG4007 #6640

frederick-vs-ja opened this issue Nov 2, 2023 · 6 comments

Comments

@frederick-vs-ja
Copy link
Contributor

[func.require]/4 reads:

[...] This forwarding step delivers a state entity of type T as cv T& when the call is performed on an lvalue of the call wrapper type and as cv T&& otherwise, where cv represents the cv-qualifiers of the call wrapper and where cv shall be neither volatile nor const volatile.

It seems that the "shall be" used here is imposing some additional requirements, and thus shouldn't be interpreted as plain "is". But the additional requirements don't seem clear.

  • Is the implementation required to ensure that when a volatile value of the wrapper is called, the invocation is ill-formed, or
  • is the user code required to ensure that a volatile value of the wrapper is not called, otherwise, the behavior is undefined, or
  • is the use of "shall" unintended, and thus a plain "is" should be used, which implicitly makes the invocation on such a volatile value unspecified?
@jensmaurer
Copy link
Member

We customarily use "shall" for constraints on the user-written program. Thus, it's the first item.

@jwakely
Copy link
Member

jwakely commented Nov 2, 2023

For the library use of "shall" it's the second, i.e. UB. This means the impl is allowed to accept it as an extension (for backwards compatibility), instead of being required to reject it as ill-formed.

@jensmaurer
Copy link
Member

Ah, thanks for the info.

@jwakely
Copy link
Member

jwakely commented Nov 2, 2023

In the interests of removing unnecessary UB, maybe we should consider making this conditionally supported, or explicitly unspecified (which would still allow it to be supported as an extension, but wouldn't open the door to nasal demons and unbounded UB).

@frederick-vs-ja
Copy link
Contributor Author

I failed to express that the current wording seemingly mixes requirements for implementations and user codes in a strange way (at least to me).

Should we editorially clarify the status quo by divorcing the requirements, or open an LWG issue to change it?

@jwakely
Copy link
Member

jwakely commented Nov 3, 2023

Please request an LWG issue, because I'd like to revisit the implied UB.

@frederick-vs-ja frederick-vs-ja changed the title [func.require] Unclear use of "shall" [func.require] Unclear use of "shall" LWG4007 Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jwakely @frederick-vs-ja @jensmaurer