freenode_#tc39.part.log

## freenode_#tc39.part.log
[2018-05-31 17:07:30 MSK] <ChALkeR> Hi all. I guess this could be finally the correct channel for my question, which I tried to ask in two other irc channels (sorry to everyone who is present in all those).
[2018-05-31 17:07:38 MSK] <ChALkeR> Probably I'm reading the spec wrong, but to me it looks like both Chrome and Firefox are doing something other than what is written in the spec in regards to object keys order.
[2018-05-31 17:07:46 MSK] <ChALkeR> Object.keys({'a': 10, '1':1, 12345678900: 2}) gives [ "1", "a", "12345678900" ] — why is that?
[2018-05-31 17:08:00 MSK] <ChALkeR> I expect [ "1", "12345678900", "a" ]
[2018-05-31 17:08:21 MSK] <ChALkeR> http://ecma-international.org/ecma-262/8.0/#sec-object.keys refers to http://ecma-international.org/ecma-262/8.0/#sec-enumerableownproperties, which refers to OwnPropertyKeys from http://ecma-international.org/ecma-262/8.0/#sec-invariants-of-the-essential-internal-methods
[2018-05-31 17:08:36 MSK] <ChALkeR> Which for ordinary objects is http://ecma-international.org/ecma-262/8.0/#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys which redirects to http://ecma-international.org/ecma-262/8.0/#sec-ordinaryownpropertykeys
[2018-05-31 17:08:48 MSK] <ChALkeR> Which states «2. For each own property key P of O that is an integer index, in ascending numeric index order, do a. Add P as the last element of keys.»
[2018-05-31 17:08:55 MSK] <ChALkeR> http://ecma-international.org/ecma-262/8.0/#sec-object-type states: «An integer index is a String-valued property key that is a canonical numeric String (see 7.1.16) and whose numeric value is either +0 or a positive integer ≤ 2^53-1. An array index is an integer index whose numeric value i is in the range +0 ≤ i < 2^32-1.»
[2018-05-31 17:09:14 MSK] <ChALkeR> 12345678900 is not an "array index", but it should be an "integer index", so it should be moved to the beginning, before "a".
[2018-05-31 17:09:59 MSK] <ChALkeR> But Chrome and Firefox (all the browsers I checked) seem to use "array indexes" there instead of "integer indexes".
[2018-05-31 17:11:17 MSK] <ChALkeR> I checked the 6.0 and 8.0 versions of the spec — both of those seem to imply that "integer indexes" should come first and that those are in [0, 2^53 - 1] range
[2018-05-31 17:13:20 MSK] <ChALkeR> Lars Knoll from Qt (https://bugreports.qt.io/browse/QTBUG-62512) also is going to implement that as "array indexes" in Qt Quick JS engine, saying that using "integer indexes" there is going to kill performance.
[2018-05-31 17:14:05 MSK] <ChALkeR> Perhaps I am reading the spec wrong? Or is this an implementation bug in all those?
[2018-05-31 17:14:14 MSK] <ChALkeR> Or is this a spec problem, perhaps?
[2018-05-31 17:42:33 MSK] <IgnoredAmbience> ChALkeR: Note step 5 of EnumerableOwnProperties, "Order the elements of properties so they are in the same relative order as would be produced by the Iterator that would be returned if the EnumerateObjectProperties internal method were invoked with O."
[2018-05-31 17:43:03 MSK] <IgnoredAmbience> This gives implementations the flexibility to order keys in some circumstances.
[2018-05-31 17:43:10 MSK] <IgnoredAmbience> *as they wish
[2018-05-31 17:43:19 MSK] <ljharb> specifically, i think for the purpose of matching for..in?
[2018-05-31 17:44:02 MSK] <IgnoredAmbience> I'm just re-reading this section now.
[2018-05-31 17:46:38 MSK] <IgnoredAmbience> I believe that section enforces no specific order on the property names.
[2018-05-31 17:47:48 MSK] <IgnoredAmbience> I can't comment on the intent of that section, though.
[2018-05-31 18:00:49 MSK] <ChALkeR> ljharb: for..in also does not put 12345678900 to the front
[2018-05-31 18:09:54 MSK] <devsnek> 12345678900 is named and 1234567890 is indexed
[2018-05-31 18:11:43 MSK] <devsnek> it switches on 2^32-2
[2018-05-31 18:12:03 MSK] <devsnek> seems like they're only optimising indexed properties that fit into signed 32 bit integers
[2018-05-31 18:13:03 MSK] <devsnek> ChALkeR: ^^
[2018-05-31 18:13:30 MSK] <devsnek> (in v8 btw)
[2018-05-31 18:15:17 MSK] <ChALkeR> Yeah, that's what "array index"es are.
[2018-05-31 18:15:54 MSK] <ChALkeR> But the spec says that "integer indexes" should come first as I read it. Though it seems no one does that.
[2018-05-31 18:16:19 MSK] <ChALkeR> IgnoredAmbience: I disagree.
[2018-05-31 18:16:30 MSK] <ChALkeR> Reflect.ownKeys({'a': 10, '1':1, 12345678900: 2}) returns [ '1', 'a', '12345678900' ]
[2018-05-31 18:17:33 MSK] <ChALkeR> http://ecma-international.org/ecma-262/8.0/#sec-reflect.ownkeys directs to OwnPropertyKeys, defined in http://ecma-international.org/ecma-262/8.0/#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys
[2018-05-31 18:17:48 MSK] <IgnoredAmbience> Hmm, noted.
[2018-05-31 18:17:49 MSK] <ChALkeR> Which has a strictly defined order.
[2018-05-31 18:18:36 MSK] <ChALkeR> And it should be [ '1', '12345678900', 'a' ] as I read the spec.
[2018-05-31 18:18:46 MSK] <devsnek> @implementors pls fix
[2018-05-31 18:18:53 MSK] <IgnoredAmbience> I think I agree with you there.
[2018-05-31 18:20:31 MSK] <ChALkeR> devsnek, idk, perhaps just s/integer index/array index/ in some sections of the spec would be a better thing?
[2018-05-31 18:20:52 MSK] <devsnek> i think implementors would prefer that
[2018-05-31 18:20:57 MSK] <ChALkeR> Given that all impls follow "array index" there.
[2018-05-31 18:21:11 MSK] <devsnek> on the other hand the current spec is saner
[2018-05-31 18:21:14 MSK] <ChALkeR> (I haven't checked MS)
[2018-05-31 18:21:28 MSK] <devsnek> i'm updating jsvu atm
[2018-05-31 18:21:30 MSK] <devsnek> i was just about to check
[2018-05-31 18:22:30 MSK] <IgnoredAmbience> The current spec for Object.keys follows the ES5 implementation-dependent ordering rule, https://es5.github.io/#x15.2.3.14
[2018-05-31 18:27:12 MSK] <IgnoredAmbience> [[OwnPropertyKeys]] was an ES6 introduction, with the ordering rule, as was the Reflect object
[2018-05-31 18:33:29 MSK] <IgnoredAmbience> A quick glance at test262 doesn't show it distinguishing the two types of index in this situation
[2018-05-31 18:33:55 MSK] <IgnoredAmbience> Any tests use low values of indexes (0,1,2)
[2018-05-31 18:35:00 MSK] <leobalter> bterlson coc meeting?
[2018-05-31 18:36:13 MSK] <IgnoredAmbience> This channel's logbot appears to have stopped working, btw
[2018-05-31 19:50:53 MSK] <bterlson> where did slurp go??
[2018-05-31 19:50:59 MSK] <bterlson> I'll try to investigate