| 03:48 | <ljharb> | bakkot: bad news for your coercion proposal, some people like it https://twitter.com/wesbos/status/1686014875040956416 |
| 07:10 | <bakkot> | ljharb: some people are incorrect |
| 14:26 | <shu> | this is someone who teaches beginner javascript, according to the twitter profile |
| 14:59 | <Anthony Bullard> | this is someone who teaches beginner javascript, according to the twitter profile |
| 14:59 | <shu> | alas |
| 14:59 | <shu> | teaching at(0.1) as a benefit seems not good to me |
| 15:01 | <Anthony Bullard> | Not going to argue that. And does somewhat surprise me |
| 15:01 | <Anthony Bullard> | I haven't been in discussions on .at() so I was unaware of the coercion |
| 15:02 | <shu> | there were no discussions around coercion specifically at the time, the method follows the coercion precedence of other methods |
| 15:02 | <Anthony Bullard> | I wasn't aware it worked with other array methods either, hadn't tried in that in my 24 years of JavaScripting |
| 15:02 | <shu> | which is the point of bakkot's proposal. we've been operating on precedence grounds for decades, it's time to rethink that |
| 15:02 | <Anthony Bullard> | Never even occurred to me to try |
| 15:02 | <shu> | yeah |
| 15:04 | <rkirsling> | huh |
| 15:04 | <rkirsling> | yeah I can't say I've ever attempted to pass a non-integral number to slice, say |
| 15:11 | <Anthony Bullard> | Strangely enough it works. Had to open a terminal to prove it to myself |
| 15:12 | <rkirsling> | yeah. |
| 15:13 | <rkirsling> | the thing is that if array[1.2] already worked like that, then you could argue that array.at(1.2) is a non-regression, or something |
| 15:14 | <rkirsling> | but given that array[1.2] is not in fact equivalent to array[1], it definitely seems hard to consider the equivalence of .at(1.2) and .at(1) a good thing |
| 15:15 | <rkirsling> | I don't necessarily mean that we screwed up |
| 15:15 | <rkirsling> | but for educational materials... |
| 15:15 | <rkirsling> | 😓 |
| 15:25 | <Anthony Bullard> | `array[1.2]` won't error though, so it's a question of what the behavior should be for `.at()` if we don't want coercion. There is a sort of coercion happening with `arr[1.2]` as well, and I don't think we would want to extend that to `.at(1.2)` |
| 15:27 | <rkirsling> | certainly, at isn't meant to string coerce |
| 15:27 | <rkirsling> | in that regard I guess an error could've been argued for |
| 15:30 | <Anthony Bullard> | My argument is that either way there is either a loss of backwards compat (nope) or a lack of symmetry between accessing an integer index or a decimal extension of said integer. |
| 15:31 | <Anthony Bullard> | I think the best case for sanity going forward would be a TypeError, but it would create more errata for devs leveraging previous knowledge |
| 15:55 | <rkirsling> | I think it's probably too late to change though |
| 16:41 | <bakkot> | my hope is a TypeError (or RangeError) for this case for new methods |
| 16:41 | <bakkot> | to break with precedent because it's a bad precedent |
| 16:41 | <bakkot> | and yeah, the main cost is to devs who have already learned the existing rules |
| 16:42 | <bakkot> | but, even among people who know those rules, hopefully not too many actually rely on them in practice |
| 17:04 | <Anthony Bullard> | Do we have tools to find such usages in the corpus? |
| 17:34 | <Chris de Almeida> | Do we have tools to find such usages in the corpus? |
| 17:35 | <Anthony Bullard> | Lovely |
| 17:35 | <Anthony Bullard> | Given that JS is dynamic, it may be hard to really nail down usages outside of literal usages |