ecma262
ecma262 copied to clipboard
tc39
Annex F fails to document a breaking change to iteration
#1021 updated IteratorNext from taking an iterator whose next method is read on every step to taking an iterator Record for which the next method is read only at creation time. This change is observable to ECMAScript code, and should be documented in Annex F.
Related:
- https://github.com/tc39/test262/issues/3937
- https://github.com/Moddable-OpenSource/moddable/issues/1223
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.
- We don't know what the intended audience or purposes of Annex F is. Who's reading it, and what are they wanting to find out? Is it more of a historical curiosity?
- It would be difficult to keep it complete. What kind of changes make the cut for "backwards breaking" and what don't? For example, existing entries like "it is no longer an early error to have duplicate property names in Object Initializers." don't seem like it should be included. We shouldn't be calling out new features as backwards breaking.
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)
