Annex B.3.3 use cases have a universally-shared bullet with imprecise language #676
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jswalden
force-pushed
the
clarify-antecdent
branch
from
593b6a0 to
1fab9ae
Compare
… and use more precise language to specify an antecedent within one of the requirements.
jswalden
force-pushed
the
clarify-antecdent
branch
from
1fab9ae to
fc6f098
Compare
|
LGTM, @bterlson ? |
| @@ -36405,18 +36405,19 @@ | |||
| <!-- es6num="B.3.3" --> | |||
| <emu-annex id="sec-block-level-function-declarations-web-legacy-compatibility-semantics"> | |||
| <h1>Block-Level Function Declarations Web Legacy Compatibility Semantics</h1> | |||
| <p>Prior to ECMAScript 2015, the ECMAScript specification did not define the occurrence of a |FunctionDeclaration| as an element of a |Block| statement's |StatementList|. However, support for that form of |FunctionDeclaration| was an allowable extension and most browser-hosted ECMAScript implementations permitted them. Unfortunately, the semantics of such declarations differ among those implementations. Because of these semantic differences, existing web ECMAScript code that uses |Block| level function declarations is only portable among browser implementation if the usage only depends upon the semantic intersection of all of the browser implementations for such declarations. The following are the use cases that fall within that intersection semantics:</p> | |||
| <p>Prior to ECMAScript 2015, the ECMAScript specification did not define the occurrence of a |FunctionDeclaration| as an element of a |Block| statement's |StatementList|. However, support for that form of |FunctionDeclaration| was an allowable extension and most browser-hosted ECMAScript implementations permitted them. Unfortunately, the semantics of such declarations differ among those implementations. Because of these semantic differences, existing web ECMAScript code that uses |Block| level function declarations is only portable among browser implementation if the usage only depends upon the semantic intersection of all of the browser implementations for such declarations.</p> | |||
| <p>These are the threshold requirements for the semantic intersection to potentially occur:</p> | |||
There was a problem hiding this comment.
I find this language complex to parse and understand. What was wrong with the old language?
There was a problem hiding this comment.
NM I see what you're doing here.
|
Pretty sure this is saying the same thing. @allenwb can you confirm? |
|
After discussion with @allenwb, we're pretty agreed that this non-normative prose is inadequate to describe the intersection semantics (which are precisely defined by B.3.3.1-B.3.3.5). A better fix here would be to just give some illustrative examples rather than trying to proseify complex algorithm steps. I can work on this. |
ljharb
force-pushed
the
master
branch
3 times, most recently
from
3d0c24c to
7a79833
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All three use cases in Annex B.3.3 have the same first bullet point: "One or more FunctionDeclarations whose BindingIdentifier is the name f occur within the function code of an enclosing function g and that declaration is nested within a Block."
And within that bullet point, "that declaration" is somewhat ambiguous as to whether it refer to function
gor to thoseFunctionDeclarations.Make the spec text apply to all three use cases, and use more-precise language to refer to those
FunctionDeclarations as antecedent.