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

"terminate is called" inconsistency #3079

Closed
jwakely opened this issue Jul 25, 2019 · 5 comments · Fixed by #4005
Closed

"terminate is called" inconsistency #3079

jwakely opened this issue Jul 25, 2019 · 5 comments · Fixed by #4005
Assignees

Comments

@jwakely
Copy link
Member

jwakely commented Jul 25, 2019

Clause [except] consistently says "the function std::terminate is called".

[support.start.term] says "the function std::terminate shall be called" (which is an incorrect use of "shall", and redundant std-qualification).

[terminate.handler] says "The type of a handler function to be called by std::terminate() when terminating exception processing" (redundant qualification, completely bogus to use () when referring to a function by name, rather than describing a function call expression).

[execpol.seq], [execpol.par], [execpol.parunseq], and [execpol.unseq] say "terminate() shall be called" (incorrect "shall", unclear if it's trying to name the function or show a call expression, but arguably either is correct).

[stopsource] and [stopcallback.constr] (added by P0660R10, #3072) say "terminate() is called".

[thread.thread.constr] and [thread.jthread.constr] (the latter added by P0660R10 #3072) say "terminate shall be called" (incorrect "shall").

[thread.thread.destr] and [thread.thread.assign] say "calls terminate()".

[thread.condition.condvar] says "terminate() shall be called" many times (incorrect "shall").

This is a mess.

@jwakely jwakely added the decision-required A decision of the editorial group (or the Project Editor) is required. label Jul 25, 2019
@jensmaurer jensmaurer added decision-required A decision of the editorial group (or the Project Editor) is required. and removed decision-required A decision of the editorial group (or the Project Editor) is required. labels Sep 10, 2019
@jensmaurer
Copy link
Member

See #2150.

@jensmaurer
Copy link
Member

Editorial meeting: Use "call" for function call expressions; use "invoke" for abstract-machine-level discussion of control flow passing to another function. Also in [basic].
For this particular issue, "the function std::terminate is invoked" (no parens).

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Oct 21, 2019
@languagelawyer
Copy link
Contributor

Editorial meeting: Use "call" for function call expressions; use "invoke" for abstract-machine-level discussion of control flow passing to another function.

This resolves CWG2166

@jensmaurer
Copy link
Member

@languagelawyer , CWG2166 has the title 'Unclear meaning of “undefined constexpr function” '. I fail to see a connection to call vs. invoke.

@languagelawyer
Copy link
Contributor

@jensmaurer CWG2166 asks: undefined when? At the time of parsing ("call") or when really evaluated (invoked)? Are mutually-recursive constexpr functions allowed?

The resolution of editorial meeting answers: when really evaluated (invoked), the standard says «expr is a const. expr unless it would evaluate ... an invocation of an undefined constexpr function». Mutually-recursive constexpr functions are allowed, bc a function can be undefined when is called, but defined when invoked.

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 a pull request may close this issue.

3 participants