-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Can [[Call]] return an abrupt completion with [[Type]] = continue|break|return? #1537
Comments
Not sure what you're saying.
[[Type]] = I think, as long as you only deal with ordinary objects (and spec-defined exotics), the only abrupt completions that any internal method can return are throw completions. But once you add implementation-defined exotics to the mix, all bets appear to be off, as there's no restriction on what abrupt completions they can return. |
cc @allenwb for background. It seems reasonable to explicitly restrict that, unless there’s a reason not to. |
See, for example: Because of these early errors, a break or continue abrupt completion can never reach https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist so it doesn't have to deal with it. Remember that this document is only a specification, not an implementation of an extensible virtual machine. As a specification it must be internally consistent but only needs to deal with what is actually allowed by other parts of the specification. Adding normative steps to deal with things that are not otherwise specified would just complicate the specification and place unnecessary normative requirements on implementations. Note that if a new feature (eg, do expressions) was added that allowed break/continue statements to used in new context then the specification of that feature would also need to either provide additional early error rules or runtime errors to ensure that break/continue abrupt completions did not escape from function bodies. Or they would need to define the full semantics of break/continue propagation across function calls (this is non-trivial. It's sometime I extensively explored for the "Block Lambda" proposals. Based upon that I don't recommend every adding it to the language). Regarding, implementation defined exotic functions. The spec. does not defined an general extension point for them other than https://tc39.github.io/ecma262/#sec-built-in-function-objects-call-thisargument-argumentslist which is only mandatory for implementation defined exotic functions that correspond to a "built function" . Step 10 of 9.3.1 should probably be elaborated to state that the evaluation of F must not be a break/continue/return abrupt completion. To cover the more general issue of implementation defined exotic functions we might add an similar essential invariant for [[Call]] in https://tc39.github.io/ecma262/#sec-invariants-of-the-essential-internal-methods |
Perhaps a non normative note that break/continue can’t be produced from a function call? |
Yes, almost suggested that. But it isn't clear where you would put that note. Really applies to the early errors for FunctionBody, ScriptBody, and ModuleBody rather than BreakStatement and ContinueStatement. For those who are concerned about exotic implementation defined functions I think adding the [[Call]] invariant is what we should do. |
Indeed. This is a question about what's allowed.
Not quite sure what you're responding to there: I don't think anyone was proposing to add normative steps.
Right, so it doesn't apply to implementation-defined exotic functions that aren't built-ins.
On the other hand, if we add the invariant, we don't have to elaborate, since the evaluation of F goes to result, which is what gets returned by the algorithm, which would thus be subject to the invarant.
Okay, so it sounds like the answer to my original question is that, while it's disallowed 'by construction' in the common cases, it's not currently disallowed in general, but should be.
I'll propose some text. |
I.e., disallow internal methods from returning abrupt completions with [[Type]] = continue or break or return. Somewhat casually in 6.1.7.2, and then more formally in 6.1.7.3. Resolves tc39#1537.
Is it allowed for the [[Call]] internal method of a function object to return an abrupt completion whose [[Type]] is
continue
,break
, orreturn
? (I'm pretty sure that no [[Call]] algorithm defined in the spec has this behavior, so it would have to be an implementation-defined function.)Allowing it would mean that a function-call could have the same effect as a
continue
,break
, orreturn
statement, which seems undesirable.However, I can't find anywhere that it's disallowed. In fact, both 6.1.7.2 Object Internal Methods and Internal Slots and 6.1.7.3 Invariants of the Essential Internal Methods are remarkably quiet about the possibility of any internal method returning an abrupt completion (even though it's clear elsewhere that they all can).
The text was updated successfully, but these errors were encountered: