| 07:18 | <Jesse> | it could have worked but I got some private feedback from a few (and public feedback from one) that it wouldn't work out |
| 07:19 | <Jesse> | the 19th is a federal holiday in the US and the rest of that week is PLDI, so these options are not great... |
| 07:28 | <Jesse> | options added |
| 22:29 | <bakkot> | so if we were going to add a
keeping in mind that plz vote with emoji reacts [note they may be out of order because Element displays the most popular ones first] |
| 23:07 | <iain> | Math.sum(...iterable) seems like a reasonable way to implement 1 using 2. SpiderMonkey already has special handling for Math.min/max(...array). |
| 23:10 | <bakkot> | iain: unfortunately no engine I have on hand is able to handle Math.max(...iterable) when iterable has more than ~70k elements |
| 23:11 | <iain> | Ah, fair enough |
| 23:12 | <bakkot> | which, a.) sometimes I do in fact have arrays with more than 100k elements and b.) because I don't know those limits offhand I would not be willing to use the ...iterable version with any array whose length is not very strictly bounded |
| 23:37 | <TabAtkins> | Yeah I'm sad about that. I mean, I like both at the same time - take a variable number of numbers-or-iterators, and sum all of them |
| 23:37 | <TabAtkins> | aka flatten the arguments array and then sum the result |
| 23:38 | <Kris Kowal> | I’ve had the same problem with splice. |
| 23:39 | <Kris Kowal> | Not that I’m suggesting that we add Array.prototype.swap or Array.prototype.patch, but |
| 23:39 | <TabAtkins> | I'll say that in most cases I find it a little annoying if something only takes an iterable versus taking N arguments, because when I'm hand-authoring I have to remember to add a wrapper. But for sum() it's not really a deal; if I'm invoking on some varaibles directly I can just... add them together instead. |
| 23:40 | <TabAtkins> | The other issue with taking a single iterable is when you have two iterables. JS doesn't have built-in chain to make that work. |
| 23:40 | <bakkot> | if only we'd thought to make Math.max throw if you passed it something non-primitive with a Symbol.iterator property... |
| 23:41 | <TabAtkins> | While argument spread handles it automatically |
| 23:41 | <bakkot> |
soon! |
| 23:42 | <bakkot> | honestly that is making me want Iterator.of |
| 23:42 | <bakkot> | we should have that too |
| 23:44 | <bakkot> | really the problem here is coercing |
| 23:44 | <bakkot> | we should stop coercing things |
| 23:45 | <TabAtkins> | Ah, an Iterator.from() would do it, yeah |
| 23:45 | <TabAtkins> | and like it's trivial to write yourself, but still |
| 23:45 | <bakkot> | Iterator.from is in the stage 3 iterator helpers proposal |
| 23:45 | <TabAtkins> | nice |
| 23:50 | <TabAtkins> | I'm sure it's not web compatible, but I wonder how many authors we'd help by throwing for a max() argument with an iterator, letting them know they meant to spread it. |
| 23:51 | <bakkot> | yeah I'd love that |
| 23:51 | <bakkot> | but someone out there is relying on Math.max([10]) giving them 10 |
| 23:52 | <TabAtkins> | i think coercing to string or to number is often fine, but our behavior where we'll coerce to string then to number is so weird and buggy |
| 23:53 | <bakkot> | I want to make a rule that we never coerce between primitives, at least |
| 23:54 | <bakkot> | also ideally never coerce Array instances |
| 23:54 | <TabAtkins> | yeah def |
| 23:54 | <bakkot> | I will probably have a bit on the agenda next meeting about this |
| 23:55 | <TabAtkins> | Having to call str() or int() in Python hasn't killed me yet. |
| 23:56 | <bakkot> | also like ['a', 'b', 'c'].at('start') // 'a' |
| 23:56 | <bakkot> | I hate that |
| 23:56 | <bakkot> | I know why it happens |
| 23:56 | <bakkot> | and it's consistent |
| 23:56 | <bakkot> | but I hate it so much |
| 23:56 | <TabAtkins> | lol |
| 23:56 | <TabAtkins> | is that a NaN->0 coercion? |
| 23:56 | <bakkot> | yes |
| 23:56 | <TabAtkins> | bleh |
| 23:56 | <bakkot> | which is the worst of all coercions |
| 23:56 | <bakkot> | and which we are at least starting to move away from |
| 23:57 | <bakkot> | take and drop in the iterator helpers proposal guard on NaN explicitly |