00:35
<shu>
i completely missed this during stage 3 review: https://github.com/tc39/proposal-change-array-by-copy/issues/88
00:36
<shu>
i don't think we discussed this during plenary, perhaps we were all under the misconception that TypedArray.prototype.splice existed
00:36
<shu>
cc yulia keith_miller hopefully it's not too late
02:32
<Ashley Claymore>
I’m OK with removing this from TA. I can’t imagine it’s too late.
05:05
<ljharb>
ES2022 was approved today, so now it's official: https://github.com/tc39/ecma262/releases/tag/es2022
07:30
<yulia>
cc yulia keith_miller hopefully it's not too late
I think we can manage something
14:15
<shu>
Ashley Claymore: i'm not strongly opposed to having it but maybe a quick re-discussion would be good, since i feel like people might've been under the assumption that TA.p.splice existed
14:17
<shu>
if we do decide to keep it it needs parameter conversion changes like https://github.com/tc39/proposal-change-array-by-copy/pull/86
14:18
<shu>
which is... kind of unfortunate, actually, because it would need temporary storage for the items
14:18
<shu>
but oh well, no different than for sort, i guess
14:21
<Ashley Claymore>
there is the "Record & Tuple Monthly Call" on the tc39 calendar for this coming Tuesday. We've been using that call to also discuss the change-array-by-copy proposal.
14:23
<shu>
if you could ask for me if folks feel strongly about having it
14:24
<shu>
i don't really have the intuition that zloirock has that Tuple is analogous here
14:24
<shu>
like, we didn't add these methods to all indexables
14:27
<Ashley Claymore>
I think its more that TA not having splice could be seen as similar to it not having push and pop. In that they modify length. (putting aside that not all inputs to splice will modify length)
14:28
<shu>
for now i guess it's safer to assume that it'll remain in, so i'll prep a PR that does the items conversion up front
14:28
<shu>
that's a good point, yes
14:28
<shu>
(but also there's no withPushed or withPopped, right?)
14:28
<nicolo-ribaudo>
Because we have .concat and .slice
14:28
<Ashley Claymore>
correct. There was orginally, but they were dropped as they have direct alternatives
14:29
<Ashley Claymore>
.concat and .slice(0, -1)
14:29
<shu>
okay, i think i'm coming around to "it's fine to have toSpliced"
14:29
<shu>
then i'd ask for the folks on the record and tuples call to just reaffirm this is a conscious decision
14:29
<Ashley Claymore>
but 100% agree, the type-conversion needs to be done up front if we do have it. To isolate the userland re-entrance
14:30
<shu>
as a rule of thumb i don't like adding extra things to TA.p because TAs are weird
14:30
<shu>
like they aren't "just" type-enforced arrays
14:30
<littledan>
yeah I'd be OK if we said, "we no longer believe in what we did in ES6 of trying to make TAs analogous to Array" FWIW, but if we want to follow that ES6 logic we'd include the method
14:31
<shu>
littledan: i don't follow the second part
14:31
<littledan>
TAs include all the Array methods that could possibly work
14:31
<littledan>
even the ones that are pretty useless-feeling
14:31
<shu>
right
14:31
<littledan>
this is a design that we could decide to carry forward here, or we could go more utility-driven
14:31
<shu>
oh "that logic" == "ES6 logic"
14:32
<littledan>
yes
14:32
<shu>
okay now i understand
14:32
<littledan>
I'd be OK with the conscious decision to reject ES6 logic, yeah
14:35
<Ashley Claymore>
for now i guess it's safer to assume that it'll remain in, so i'll prep a PR that does the items conversion up front
thanks. Im happy to put the PR up if you could do with one less thing on your plate
14:35
<shu>
oh much appreciated, that'd be nice
14:35
<shu>
tag me for review please
14:35
<Ashley Claymore>
on it
15:00
<shu>
I'd be OK with the conscious decision to reject ES6 logic, yeah
that's my preference for sure, at least going forward
15:00
<Ashley Claymore>
https://github.com/tc39/proposal-change-array-by-copy/pull/89/files