> - const foo = function(a, b) { ... }
> + const foo = (a, b) => { ... }
Assuming this is JS code, these differences should not be ignored, as an arrow function can behave differently than a traditional function.
> + const foo = (a, b) => { ... }
Assuming this is JS code, these differences should not be ignored, as an arrow function can behave differently than a traditional function.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
var x = 3 will escape the latter.
function foo1() { ... }
const foo2 = function() { ... }
const foo3 = () => { ... } (function () {
var x = 0;
const foo1 = function(a, b) { var x = 2; }
const foo2 = (a, b) => { var x = 3; }
foo1(); console.log(x); // prints 0
foo2(); console.log(x); // prints 0
})()
const foo1 = function(a, b) { return a + b; }
(2, 3)
console.log(foo1) // prints 5
const foo2 = (a, b) => { return a + b; }
(2, 3)
console.log(foo2) // prints [Function: foo2] > const foo1 = function(a, b) { return a + b; }
(2, 3)
> console.log(foo1) // prints 5
> const foo2 = (a, b) => { return a + b; }
(2, 3)
> console.log(foo2) // prints [Function: foo]
A super nice example of how subtle differences can really change things though.
As a side note, ASI for JS is actually super easy to implement and the rules are actually really simple (leaving aside whether the feature itself is good :D ) as it's just "these specific statements can have a new line instead of a semicolon" - so in the parser instead of consume(semicolon) you can just do "semicolon or newline" (You can check the logic in JSC in https://github.com/WebKit/WebKit/blob/main/Source/JavaScript... - just look for autoSemicolon() or autoSemi() I can't recall off the top of my head)
lmao what a p
If the tool could show you, for example, "this change is functionally identical except for when the sum of the two inputs overflows a UInt64", that'd be pretty cool.
If you want to boil down what devs are looking for in a diff tool to one thing, it would be "which change(s) between these two versions of code result in a different binary (or AST/opcodes/bytecode, depending on the language)?" All other changes, while certainly sometimes useful to know about, are just syntactic sugar.
I think those are meant to be illustrative of an idea rather than exact examples.