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

don't use "is called" to introduce a definition #3515

Open
zygoloid opened this issue Nov 26, 2019 · 2 comments
Open

don't use "is called" to introduce a definition #3515

zygoloid opened this issue Nov 26, 2019 · 2 comments
Labels
big An issue causing a large set of changes, scattered across most of the text.

Comments

@zygoloid
Copy link
Member

We have decided to use "call" to mean a function call expression (see #3079). So we should stop using it to introduce definitions.

We should use a different phrasing to avoid this. For example, instead of:

For every iterator type X, there is a corresponding signed integer-like type called the difference type of the iterator.

Consider:

For every iterator type X, there is a corresponding signed integer-like type known as the difference type of the iterator.

Or:

The difference type of an iterator type X is a corresponding signed integer-like type, determined as specified in [incrementable.traits].

@jensmaurer jensmaurer added the big An issue causing a large set of changes, scattered across most of the text. label Dec 2, 2019
@jwakely
Copy link
Member

jwakely commented May 22, 2020

Does this mean it's wrong to refer to "the caller" of a function? e.g. [new.handler] (2.3) "terminate execution of the program without returning to the caller."

The decision seems to mean that "call" is a static property of the source code, whereas some uses of "the caller" in the IS are a dynamic property of a particular invocation at run time. Changing to "the invoker" doesn't seem like an improvement (everybody knows what "the caller" means).

We also have "the calling thread of execution" ([algorithms.parallel.exec] p4-5) which is also a runtime property, and several uses of "calling thread" in the Threads clause.

I'm also trying to determine what to change in the Networking TS, which talks about "the calling thread" and also has gems like:

where g is a function object of unspecified type that, when called as g(), performs fd().

(I'm considering "unspecified type such that the invocation of g() invokes fd()" but I don't really like that either.)

@jensmaurer
Copy link
Member

I think "caller of a function" is sufficiently unambiguous; "invoker" sounds stupid.

"calling thread" probably can bear with some improvement; maybe "the thread on which the function is invoked"? This would also fix the category error that a "thread" calls something (no, another function calls something).

"when called as g()" seems fine (this is [expr.call]); maybe simply replace "performs" with "evaluates".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big An issue causing a large set of changes, scattered across most of the text.
Projects
None yet
Development

No branches or pull requests

3 participants