ecma262
ecma262 copied to clipboard
tc39
Editorial: document forbidden extension
This restriction has previously been documented in the section titled "ECMAScript Standard Built-in Objects". Include it in the section designed to summarize all such restrictions.
I tried to match the original language. That said, the original language might be a little confusing out of context. Maybe this would be better:
- An implementation must not throw a TypeError from a built-in function based simply on the presence of an argument which is not defined by this specification.
I think you have to allow editing in this PR: https://github.com/tc39/ecma262/runs/4042060169?check_suite_focus=true
No, the issue is that PRs from forks that aren’t your own - in this case, bocoup - don’t actually allow force pushing by collaborators.
@jugglinmike can you add me to bocoup’s fork? That way we’ll be prepared to land this when it’s time. (this can be avoided in the future by making all PRs from your personal fork)
Just out of curiosity, is this supposed to specifically be a TypeError and not any Error?
I'm not sure this belongs in 17.1. In the context of clause 17, an 'extension' is (roughly) where an implementation takes a Script/Module that would (in a 'minimal' implementation) throw an error, and replaces that outcome with some non-error behavior. And then 17.1 lists the few cases of error-to-non-error that are forbidden. But what you're describing (as forbidden) is the opposite, turning a particular non-error into an error.
Thanks, @jmdyck. I can see now that still other restrictions are not present in this section (e.g. "an ECMAScript implementation must not provide any means to observe a key of a WeakMap that does not require the observer to present the observed key."). Your rough "error behavior" reading might demonstrate that this is intentional.
Still, I don't think it's very far-fetched to interpret the term "extension" to mean "any observable behavior not specified by this document." If the term is actually more specific than that, I'd like to explain in the section's description.
Do you know why it's useful to only summarize those specific kinds of restrictions? That might help me write a more precise explanation.
Still, I don't think it's very far-fetched to interpret the term "extension" to mean "any observable behavior not specified by this document." If the term is actually more specific than that, I'd like to explain in the section's description.
I agree that 17 could be clearer.
Do you know why it's useful to only summarize those specific kinds of restrictions?
That phrasing suggests to me that you might have the wrong idea about 17.1. E.g., you might be thinking of it like Annex C, which just collects + restates all the strict mode restrictions that are expressed in the body of the spec. (So, if Annex C suddenly disappeared, you could more-or-less reconstruct it.) But that isn't true of 17.1. As I understand it, nothing outside of 17.1 tells you what should be in 17.1. As @allenwb says:
The current "forbidden extensions" were all carefully selected to address very specific concerns.
So 17.1 doesn't summarize specific kinds of restrictions.
(Or maybe I've misunderstood your question.)
The spec's conformance model can be a bit hard to grasp. The vast bulk of the spec (all the grammars, pseudocode, and prose) define an abstract model of an ECMAScript processor, so it's tempting to conclude that the behavior exhibited by that model (ignoring some non-determinism) is the behavior required of compliant implementations. But really, that's just a baseline, a first approximation. You then have to apply clauses 2 and 17. Roughly speaking, I think the second-level approximation is:
- If the baseline's behavior doesn't involve throwing an error, then a compliant implementation is required to exhibit that behavior.
- But if the baseline's behavior does involve throwing an error, then a compliant implementation is free to do just about anything, other than things forbidden by 17.1.
(But I'm pretty sure there are exceptions to both points. E.g., the model has no memory constraints, so will never throw an out-of-memory error, but I think an implementation can do so and still be compliant. And maybe there are categories of baseline error behavior that compliant implementations do have to reproduce; I'm not sure. And realistically, the freedom of point 2 would be limited to what the implementation has said it will do.)
Anyway, I bring all that up to say:
- There are a couple levels involved, and a restriction at the upper level (a forbidden extension in 17.1) might look similar to a restriction at the lower level (some baseline behavior), but the implications are different.
- Most lower-level restrictions don't have a corresponding upper-level restriction.
- The set of upper-level restrictions is completely up to TC39, and is not conveyed by anything outside of 17.1, I think.
As @allenwb says:
The current "forbidden extensions" were all carefully selected to address very specific concerns.
So 17.1 doesn't summarize specific kinds of restrictions.
(Or maybe I've misunderstood your question.)
Ah, now I understand--thank you! (That discussion thread is fascinating, by the way.) Do you think section 2 or 17.1 would benefit from some acknowledgement that there are additional normative restrictions throughout the standard?
On the one hand, from a conformance standpoint, the distinction between "restriction" and "requirement" might not be so interesting. On the other, the conformance model is generally so permissive that I wonder if it's worth simply adding that, "17.1 is not exhaustive."
Do you think section 2 or 17.1 would benefit from some acknowledgement that there are additional normative restrictions throughout the standard?
I wouldn't phrase it like that, but I think 2 or 17.1 could be clearer about the compliance model and/or what is/isn't compliant behavior.
I wonder if it's worth simply adding that, "17.1 is not exhaustive."
Not sure what you mean. As I understand it, 17.1 is exhaustive: it lists all the forbidden extensions.
Right, I got tripped up by the definition of "extension" again. Maybe that's what's missing from the compliance model.
No, the issue is that PRs from forks that aren’t your own - in this case, bocoup - don’t actually allow force pushing by collaborators.
@jugglinmike can you add me to bocoup’s fork? That way we’ll be prepared to land this when it’s time. (this can be avoided in the future by making all PRs from your personal fork)
That could be a issue. What about this error/requirement in the run I linked to you before?
Error: This pull request must have the “allow edits” checkbox checked.
@Gomesz785 yes, that’s what I’m talking about. That fails when you make a PR from a fork you don’t own.
@Gomesz785 yes, that’s what I’m talking about. That fails when you make a PR from a fork you don’t own.
:ok:
My comments has been hidden, not sure commenting about a ssetting of a PR itself falls into one reason here: https://docs.github.com/assets/images/help/repository/choose-reason-for-hiding-comment.png, I am open for suggestions.
