Re:SvelteKit Is in Public Beta
by marcus_cemes on Wednesday March 24, 2021 @04:27AM
(#26564760)
Javascript does a lot of implcit conversions, it was badly designed and has dynamic types which means a lot of runtime checks, these quirks can't be removed with breaking a lot of legacy code.
Unsafe equality: "1" == 1 is true (string and float, https://dev.to/mkrl/javascript-quirks-in-one-image-from-the-...).
Yet, like with C, you learn the different ways you can shoot yourself in the foot over time and avoid them. In 10 years I've never written a safe_not_equals function, although explicit object/null checks are a thing, but it wouldn't surprise me if libraries used by millions that may end up in Internet Explorer go that extra step. Each language has it's particular use-case, JS happens to be the language of web development.
Although I agree with you in principle, in practice most of js devs never worry about such things. It's mostly library authors and such.
And there are cases where a != a, I think for NaN (not a number).
Re:SvelteKit Is in Public Beta
by nonameiguess on Wednesday March 24, 2021 @10:31AM
(#26567711)
Fair enough. It makes sense for NaN, but languages like Rust and the various ML variants solve that by defining floating point numbers to not be a type where equality is a valid binary operation.
export function safe_not_equal(a, b) { return a != a ? b == b : a !== b || ((a && typeof a === 'object') || typeof a === 'function'); }
Why is it possible for a != a to not always be false and b == b to not always be true? How did Javascript defeat the most immutable rule of basic logic discovered by Aristotle 2000 years ago?