Editorial: Add "!" before infallible calls#660
Editorial: Add "!" before infallible calls#660gibson042 wants to merge 7 commits intotc39:masterfrom
Conversation
| 1. Assert: Type(_tag_) is String. | ||
| 1. Assert: Type(_options_) is Object. | ||
| 1. If IsStructurallyValidLanguageTag(_tag_) is *false*, throw a *RangeError* exception. | ||
| 1. If ! IsStructurallyValidLanguageTag(_tag_) is *false*, throw a *RangeError* exception. |
There was a problem hiding this comment.
given 262's completion reform, where most AOs don't need to return completions, would it make more sense to update 402 to match rather than adding a bunch of prefixes?
There was a problem hiding this comment.
Yes, quite possibly. Do you have a sense of what that would like like here?
There was a problem hiding this comment.
I’d expect a separate PR that updates every AO to use the new signature, and ecmarkup will enforce that only those that return completion records are used with the ? or ! prefix - and predicates all don’t.
It’s probably a good amount of work, but it’s also probably a good idea to do before 2022, so the two 2022’s can match.
There was a problem hiding this comment.
We're hoping for the upcoming TC39 plenary to approve the 2022 spec, and my other open PRs have more material impact. I'd therefore like ECMA-402 completion reform to follow those, but only one is considered necessary for the 2022 edition so there probably won't be time to make the cutoff.
There was a problem hiding this comment.
that makes sense, but i'm not actually sure the 402 spec is valid anymore since the implicit completion rules for AOs in the 262 spec it relies on no longer exist.
in other words, i'm not sure the 402 2022 spec can be cut until the completion reform is done :-/
There was a problem hiding this comment.
Given that the use of completion records in 262 was technically "invalid" for years, I don't think completion reform needs to block cutting the 2022 edition unless the current state is actually unclear to human readers.
There was a problem hiding this comment.
Completion records were described as only containing ECMAScript language values, but held many other types of values.
(Also the "Any reference to a Completion Record value that is in a context that does not explicitly require a complete Completion Record value is equivalent to an explicit reference to the [[Value]] field of the Completion Record value unless the Completion Record is an abrupt completion." wasn't really precise enough to be meaningful.)
|
Can you review the |
|
@Ms2ger Done, along with some other broad patterns (although I'd like to stop here for the other PRs to settle before addressing the rest in a followup). |
This cleans up some calls that are not already addressed by my other open PRs (#602, #610, #625, #630).