-
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
Annex F fails to document a breaking change to iteration #3188
Comments
Annex F doesn't document all observable changes. It's always a judgement call whether a given change is worth documenting. IMO this one probably isn't, though I'm open to hearing arguments (e.g. if any in-the-wild programs broke). |
Yeah it's likely not something that will impact most (or any) program. The missing test and lack of pick up by an implementation however is more worry some. Looks like test262 cases were updated for the change, but a test262 issue was open later to indicate coverage was not sufficient, but that seems to have fallen through the cracks. |
Observable changes are sufficiently rare that I think the default should be to document them, with exclusion requiring specific justification. |
The 262 editors discussed this, and we're not clear on the purpose or the utility of Annex F as it stands. We plan to bring this to committee to gather more input from other delegates to see if they find it useful. Our personal opinion is roughly that it might not be useful enough to warrant keeping and keep maintaining.
|
Also, in reality it turns out that adding new properties to Array.prototype causes real-life breakages more often than most of the stuff listed here, but I have a hard time imagining that listing every new prototype property as a breaking change is worth doing. |
Making something that errors no longer error isn't breaking; intentionally making a change that could break existing code is. While it's a fair point that new globals and prototype methods could qualify, I would assume these don't "count". What's left is what I would assume Annex F contains. |
I think we also had a change to eval (I think indirect eval) to enable jits to do certain kinds of work… do you know why the change to wasn't recorded? i don't know the details. It is the case that I think of when I think of breaking changes and I would love to have it written down for the future. the list as it is does not seem very useful. It would take some work to make it useful and I think this is worthwhile to do. I'd like to have something that records breaking changes and why we did them. This will help us make decisions, especially if we have a classification of types of breaking changes. I agree, it isn't very useful to list every error that has been used up for adding new functionality: this can be covered with more broad language that i would be happy to help with. We are just so used to doing it and it can be confusing when viewed from the outside (I have spoken to people who were confused by this). Namely, you can't run a program that uses new syntax on an older browser, it is not backwards compatible. In the same vein, we can broadly cover a class of changes to prototype properties, as mentioned by @bakkot. It also looks like this can be cleaned up to use more consistent language (i can make a PR) |
#1021 updated IteratorNext from taking an iterator whose
next
method is read on every step to taking an iterator Record for which thenext
method is read only at creation time. This change is observable to ECMAScript code, and should be documented in Annex F.Related:
next
caching in array-destructuring? test262#3937next
for array-destructuring Moddable-OpenSource/moddable#1223The text was updated successfully, but these errors were encountered: