Do records (record<>s) purposefully throw on any object with an enumerable Symbol-named property?

[bzbarsky]

Walking through https://heycam.github.io/webidl/#es-to-record for an object with an enumerable Symbol-named property, what happens?

1. [[OwnPropertyKeys]] includes the symbol in the list.
2. desc.[[Enumerable]] is true.
3. Converting to the key type calls https://heycam.github.io/webidl/#es-to-DOMString (or one of the other string conversion functions), which calls ToString, which lands in https://tc39.github.io/ecma262/#sec-tostring and throws.

Is this by-design?

// cc @jyasskin @domenic @tobie @heycam @annevk

[bzbarsky]

Oh, and as a data point, Gecko current equivalent (MozMap) skips Symbol-named props instead.

[jyasskin]

I didn't consider the case of Symbol-named properties. The existing implementation in Mozilla is a good argument to allow-and-ignore Symbol-named properties. On the other hand, we meant folks to create the ES object specifically to pass into the record<> argument (evidence: we didn't search the prototype chain), and accidental Symbols are unlikely in that case, which argues for diagnosing them.

[domenic]

Let's call this by-design :)

[bzbarsky]

@domenic Do we have tests for this by-design behavior?

[domenic]

Probably not... let's reopen until we can be sure.

[bzbarsky]

I'm going to write some tests in https://bugzilla.mozilla.org/show_bug.cgi?id=1366032 fwiw.

[bzbarsky]

But note that right now no browsers throw here, so it could be a compat risk.... We'll see.

[bzbarsky]

In particular, Chrome's handling of this right now seems to match Firefox's: the symbol-named props are ignored.

[bzbarsky]

And Safari's matches in terms of not throwing, though not some of the other MOP details.

[rakuco]

In particular, Chrome's handling of this right now seems to match Firefox's: the symbol-named props are ignored.

I purposefully followed Gecko and what was discussed here when adding support for records in Blink. In any case, record support landed in M59, which is still in beta so I guess it's still easier to change the behavior if necessary.

[rakuco]

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=724481 to keep track of this in Blink.

[yuki3]

Is this consistent with ECMAScript? I'm not an expert, but neither of 7.3.21EnumerableOwnProperties nor 13.7.5.15EnumerateObjectProperties seem throwing an exception. Probably I should look at different places. I'm just wondering if it's consistent with ECMAScript or not, and if not, we can update the spec instead of the implementations.

[domenic]

The proper thing to compare with is the public built-in ECMAScript APIs, not the internal spec operations that they use. The only case that seems to accept an arbitrary object with user-supplied keys is Object.defineProperties (and Object.create(), which reuses the same logic). I suppose maybe Object.assign as well.

However, I'm not sure how helpful these comparisons are, because in both cases symbols are a reasonable value. There's no conversion performed, whereas with record<DOMString, x>, or for that matter record<ByteString, x>, we explicitly need to ensure that all the keys are DOMStrings (or ByteStrings).

We have a choice as to how we do this: do we ignore things that do not fit the preferred type, or do we throw? I think throwing is most consistent with other parts of Web IDL. Besides, for the record<ByteString, x> case, it would be very weird to ignore keys that could not be converted by a ByteString (e.g. keys with non-ASCII characters); throwing makes sense there. And so I think it also makes sense for keys, like symbols, that cannot be converted to DOMStrings.

[yuki3]

Thanks for the explanation. Makes sense.