You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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".
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:
Consider:
Or:
The text was updated successfully, but these errors were encountered: