4 ms·

> - const foo = function(a, b) { ... } > + const foo = (a, b) => { ... } Assuming this is JS code, these differences should not be ignored, as an arrow functi

• olliej 2y ago
  Yeah I came to say that these are not semantically equivalent (I guess you _could_ verify equivalence if you ensured it did not use this or eval)
• kqr 2y ago
  Yeah, that was a bit of an unfortunate example for a blogvertising post. Even I as a non-frontend developer knew to watch out for that one. A company working with semantic diffs should really know better and such mistakes do not inspire confidence for me!
• persnickety 2y ago
  Same goes for the loop example, where the i variable has a different scope. I think those are meant to be illustrative of an idea rather than exact examples.
  • kqr 2y ago
    But if they have worked in this field for a few months, shouldn't they have a crapton of exact examples to draw from? If not, isn't that worrying?
    • persnickety 2y ago
      Depends on how technical the audience of this post should be. Putting an accurate example which is only understandable to someone with years of experience might make newbies think it's a made up concern.
• culi 2y ago
  More specifically, the `function` keyword version of an anonymous function preserves the keyword `this` whilst the arrow syntax anonymous function does not. Arrow functions also cannot use the `yield` keyword nor be used as constructors https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#call_apply_and_bind https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  • egnehots 2y ago
    There is also the function scope vs block scope... var x = 3 will escape the latter.
    • jolmg 2y ago
      If you mean the following, it actually doesn't: (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 })() However, there is the difference in how the implicit semicolons are inserted: 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]
      • olliej 2y ago
        haha, oh ASI - I was very confused by your example as I read this as if it was > 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] Even though it makes no sense for (2, 3) to be a result in those cases, that was just how I ended up reading it, and I was exceptionally confused about how the printed output could possibly happen. 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/JavaScriptCore/parser/Parser.cpp 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)
• glhaynes 2y ago
  My guess would be that quite a large portion of changes we'd expect at a glance to be identical aren't, especially for inputs that would not be expected. I'd also guess this is much more likely in languages in which valid code commonly produces undefined behavior. 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.
  • culi 2y ago
    I think you've answered the question posed by the title here. That's feels too far
  • kmoser 2y ago
    That would neat, although I suspect most compilers/linters should already be able to warn you about potential overflows. 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.
    • tsimionescu 2y ago
      Literally every time you add/subtract/multiply two variables there is a potential overflow. In relatively rare cases, the compiler might be able to prove that they can't overflow, but in the general case it can't, and I doubt any actually do.