Sounds too like performance gains will depend on how often the branch is taken which seems highly dependent on the values that are being converted?
Most languages don't start with a spec, so the semantics of a lot of these get later specced as "uhhhhh whatever the C compiler did by default on the systems we initially built this on".
Using that list to answer your question is a bit tricky, since it also includes backward-compatibility breaks with newer features. But, e.g.,
> In ECMAScript 2015, ToNumber applied to a String value now recognizes and converts BinaryIntegerLiteral and OctalIntegerLiteral numeric strings. In previous editions such strings were converted to NaN.
and
> In ECMAScript 2015, the Date prototype object is not a Date instance. In previous editions it was a Date instance whose TimeValue was NaN.
sound like backward-incompatible changes to a JS 1.1 behavior.
Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks...
can you explain what you mean? Did early js implementations not have functions inheriting the block scope?
There are also differences in how eval works, etc
Not to my recollection. I don’t recall anyone at uni discussing a C standard until 1989, and even by 2000 few compilers were fully compliant with that C89 spec.
There were so many incompatible dialects of FORTRAN 77 that most code had to be modified at least a bit for a new compiler or hardware platform.
All of the BASIC and Pascal variants were incompatible with each other. They were defined by “what this implementation does” and not a formal specification.
No it wasn’t. K&R was far removed from many C implementations of the time, wasn’t ever written as a formal spec, and had gaping holes of undefined behavior.
An educational textbook isn’t a formal language specification.
The specification was the language, the fact that there was an implementation was a bonus. I never once in my comments above said "formal" so perhaps we are meaning two very different things by "specification." No version of Cs specification since K&R has done away with undefined, nor implementation defined behavior.
How could this be when zero implementations behaved in accordance with K&R?
The authors and fans may have claimed it as a “spec”, but it never was a functional “spec” in the real world.
Or did you mean by "taken" that the branch instruction has to be executed regardless of whether the branch is taken or not?