151–153 of 153 posts
This is going to confuse C++ developers where vector::at() explicitly throws exceptions on out of bounds access But I guess the intersect between C++/JS developers is too small to care
However I think there is a better way to support that - make `throw` an expression rather than a statement. Then you can do
a[10] ?? throw new Error()
Earlier quoted context omitted.
I've learned ages ago that parseInt cannot be used like this, so it's not a problem for me, but I thought linters already take care of this case? Also I wasn't talking about using parseInt, a broken function like this so I'm not sure what the quirks of old, widely known bad parts of Javascript have to do with using functions as arguments, which is one of the most powerful features of the language.
There's nothing broken about parseInt. The problem is, it can take a second argument(radix), and .map will feed it current item's index as the second argument(and the whole array as the third, but that one will get ignored). const arr = ['1','2','3']; arr.map(parseInt) is equivalent to: [ parseInt('1', 0, arr), parseInt('2', 1, arr), parseInt('3', 2, arr) ];
Earlier quoted context omitted.
ramda and date-fns are full of little such functions... The fact that util packs like these and lodash exist is a sign that Javascript's stdlib lacks mechanisms to deal with various common patterns. FWIW, I consider `at` to be similar to some of the things you consider "new capabilities". `fetch` vs `XMLHttpRequest` is fairly analogous to `at` vs `arr[i]`, and similar arguments can be made about ES6 classes over prot…
ramda is an immutable library - javascript is immutable. Some functions of date-fns could probably be part of the core, and in fact that's one of the areas I wish the JS WG would focus on as Date is just not a very useful class. > `fetch` vs `XMLHttpRequest` is fairly analogous to `at` vs `arr[i]` If you consider all syntactic sugar to be equivalent, no matter how minor the change, then anything above a basic Turing…