121–130 of 153 posts
So instead of fixing the language and allow to use array[-1], they add an other way to access array element. This is why I don't like JavaScript, instead of fixing feature, they add new feature to fix previous feature.
And, btw, your definition of "fixing" is broken.
Earlier quoted context omitted.
Isn't Windows even more epic?
You might well be right! Would be fun to see them go head-to-head over the title.
It's not easy, and it certainly leads to annoying platform quirks, but it is possible.
Earlier quoted context omitted.
> Reinventing the wheel is error prone. Having a standard lib for these sort of functions is a common pattern many languages adopt.
Isn't that really a pattern that the runtime adopts (i.e. not the language itself)? For ES, the libraries are dependent on the runtime environment; for browsers, there are the web APIs, and for Node, there's npm. I'm not sure how you could have anything more standard given the nature of things.
True, NodeJS runtime comes with its own «standard library» but npm has nothing to do with it.
So instead of fixing the language and allow to use array[-1], they add an other way to access array element. This is why I don't like JavaScript, instead of fixing feature, they add new feature to fix previous feature.
Earlier quoted context omitted.
array["at"] = "lunchtime"; Is also valid javascript... And will break functionality in this proposal!
I think this is the point of the stage 3 proposal. Browser makers start implementing the feature and releasing it in the development and beta versions of their browsers. Then if the users of the experimental features start noticing that webpage break, the proposal will get an update. If I remember correctly, this exact thing happened to `Array.prototype.flatten` which got renamed to `Array.prototype.flat` after it wa…
https://github.com/tc39/proposal-relative-indexing-method#we...
Earlier quoted context omitted.
Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.
TC39 explicitly rejected this sort of approach a few years ago, because of the unpleasant way it would fork the web. They _did_ automatically clean up some behavior in a module context when you knew you were using a modern JS engine, but they kept that to a minimum. Unfortunately, I couldn't find any links to articles written at the time about this, but they definitely did consider "use" options or script type="es202…
0. It will end up completely unnoticed, because everyone is using any language you like and compiles to web assembly, which is the defacto standard for more than a decade.
1. It's like a new C++, because of the many TC39 stage 3 proposals that has been added over the years without the possibility to ever fix the language in order to not fork the web.
Earlier quoted context omitted.
How do you fake BigDecimal with BigInt? My immediate intuition would have a 3-tuple ( a , b , c ) which would construct the decimal with a representing the numbers before the decimal separator, b the number of zeroes immediately after the decimal separator, and c the numbers after the zeroes. e.g. 1.000054 would be represented as `[1n, 4n, 54n]` and 3.14159 as `[3n, 0n, 14159n]`. Is there a better way?
What about a 2-tuple with two numbers, one being the BigInt and one being the exponent. So 1.000054 would be (1000054, -6) = 1000054*10^(-6). Yours is probably more space efficient though.
IEEE 754, BTW, allows for 10-based floats, but IDK if anybody uses it.
const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?
Subtle readability improvements on patterns that see extensive use actually make a difference. I had the exact same thoughts when `.includes()` was proposed to be added to the spec - it's just `.indexOf() !== -1`! - but time has proven me wrong, and I suspect it will prove us wrong about `at` as well. I've written an `.indexOf() !== -1` check hundreds if not thousands of times, and I've gotten the conditional wrong e…
Also: `[1, NaN, "hi"].indexOf(NaN)` is -1 but `.includes(NaN)` returns true as expected.
JS urgently needs support for decimals [1] and thus be able to enter sectors such as scientific and financial. V8 + dynamic language + better math support = perfect environment for many applications out there [1] https://github.com/tc39/proposal-decimal
Earlier quoted context omitted.
Your number guard is insufficient. NaN, infinity, 2.23 are all Number but not supported values for the function. This goes to show that it's NOT trivial to implement in a robust way.
It is trivial. It requires a few more lines than my example, but my example was intended to show the core use case. All I'm getting in replies is nitpicking about my example case... Can't you just assume when reading that I know how to write some simple guard statements? It's hardly rocket science.
To invert your argument, why would you want millions of developers to have to waste their time writing this sort of thing for such a common need?
Yes, it's clear that you could write the function correctly.
Could everyone?
What about bugs that aren't obvious? The runtime errors that result?
Why would we want to waste so much developer time and effort globally, when we can just add .at() to the language?