TC39 General
2024-09-25
plaintext logs
prev next
source on github
17:43
<snek>
There is still the old issue about `f() = y` being legal syntax in engines
its never too late for array.at(-1) = y
17:44
<bakkot>
😠
18:12
<TabAtkins>
You're right, we just need hookable square brackets, so array.at[-1] = y works
18:12
<Domenic>
There was a harmony wiki page for that from Allen I think...
18:12
<TabAtkins>
Yup, was referring to that obliquely ^_^
18:14
<Domenic>
There are such treasures hidden in those archives... look at what they took from us https://web.archive.org/web/20160429210828/http://wiki.ecmascript.org/doku.php?id=harmony:object_extension_literal_class_pattern
18:34
<snek>
is web archive the only place that the old wiki data exists now
18:47
<rickbutton>
does anyone know off top-of-head where in test262 the "Array prototype method property sets occur in 'strict mode'" semantics are asserted? having a hard time locating that sort of check in the Array prototype method tests. Any one of them for a prototype method would work, just want to assert something locally.
18:52
<bakkot>
by "strict mode semantics" do you mean like throwing if the assignment fails? if so, https://github.com/tc39/test262/blob/0c784ef9541fad7e38036a5e6019990ddad81659/test/built-ins/Array/prototype/fill/return-abrupt-from-setting-property-value.js is an example
18:53
<bakkot>
or https://github.com/tc39/test262/blob/0c784ef9541fad7e38036a5e6019990ddad81659/test/built-ins/Array/prototype/push/set-length-zero-array-length-is-non-writable.js
18:54
<bakkot>
generally tests for Array.prototype methods live under built-ins/Array/prototype and then old tests have uninformative names but new ones you can usually guess what they're getting at from the name
18:55
<rickbutton>
yeah exactly, throwing if assignment fails
18:56
<rickbutton>
and yeah I was looking there, but missed that second one you linked, ty!
18:57
<rickbutton>
It doesn't quite hit the specific edge case I'm testing, where an array-like with specifically a getter only property is set, but close enough for now.
22:21
<sirisian>
its never too late for array.at(-1) = y
Even rbuckton 's ref proposal doesn't allow that sadly. let ref x = array.atRef(-1); x = y; or array.at(-1).value = y; I think, haven't looked at it in a while.
22:23
<rbuckton>
Also, extractors make array.at(x) = y mean something else.
22:23
<snek>
ah good call, we'll need to cancel extractors /s
22:23
<shu>
why do people want to type a[-1] = x anyway
22:24
<snek>
when you have a stack, the end of the array is the main area you work with
22:25
<snek>
i guess you could use shift/unshift but the performance of that across engines and such is not great not terrible
22:26
<shu>
like, not just peeking at the top of the stack, but actually overwriting it?
22:26
<rbuckton>
You're right, we just need hookable square brackets, so array.at[-1] = y works

I'd love to have hookable indexers, something like:

class C {
  get this[key]() { ... }
  set this[key](value) { ... }
}

I was just discussing this in the context of the shared structs proposal the other day, since a SharedArray can't have extra properties while a normal Array can.

22:26
<shu>
or as an optimization to avoid a pop/push?
22:27
<rbuckton>
There is/was a proposal for relative indexing, i.e. ar[^1]
22:28
<shu>
i wonder if we can actually just break negative integer indices behavior
22:28
<snek>
it probably is an optimization to avoid pop/push sometimes. but other times it may just match the intent more.
22:29
<shu>
v8 not signing up for gathering compat data though
22:30
<snek>
that's ok we can just overwrite arc's firebase to inject a script to collect the data
22:30
<rbuckton>
There is/was a proposal for relative indexing, i.e. ar[^1]
I can't find it, but it was discussed in the context of the slice notation proposal.
22:31
<snek>

I'd love to have hookable indexers, something like:

class C {
  get this[key]() { ... }
  set this[key](value) { ... }
}

I was just discussing this in the context of the shared structs proposal the other day, since a SharedArray can't have extra properties while a normal Array can.

this has definitely interested me at times. i don't think i'd be against it but i'd feel a bit bad about dropping more exotic objects on implementers 😅
22:33
<rbuckton>
this has definitely interested me at times. i don't think i'd be against it but i'd feel a bit bad about dropping more exotic objects on implementers 😅
The discussion was about how making indexers first class would allow us to decrease the number of exotic objects. Most of them are "exotic" because they have unique indexing capabilities. An actual indexers proposal would need to handle more than just get/set though.
22:33
<bakkot>
i wonder if we can actually just break negative integer indices behavior
certainly not for reading; lots of code walks past the end of arrays and looks for undefined. probably not for writing either
22:35
<bakkot>
or as an optimization to avoid a pop/push?
I have code which does arr[arr.length - 1] = foo somewhere on the order of billions of times per day, yes. though I don't think arr[^-1] or whatever would be notable faster
22:36
<rbuckton>
in the relative indexing syntax, ^ means "from end", so you'd just write arr[^1], not arr[^-1]