Normative: Permit serialization of BigInt#3480

littledan · 2018-02-17T22:34:59Z

The goal of this PR is to integrate BigInt with HTML serialization.

This patch

Adds BigInt to the "safe list" of primitives permitted for
serialization.
Adds serialization of BigInt wrappers, analogous to other wrappers.

Note that BigInt, like (the unserializable) Symbol does not have a
new-able constructor: use of wrappers is explicitly discouraged by
the specification. Nevertheless, this patch adds serialization support
for consistency with other wrappers.

web-platform-tests against postMessage on BigInt are out for review in
web-platform-tests/wpt#9565

/infrastructure.html ( diff )
/references.html ( diff )
/structured-data.html ( diff )

domenic · 2018-02-17T22:38:47Z

Primitives are only serialized if they are on the safelist in step 4 of StructuredSerializeInternal. Should we allow them to be serialized too?

littledan · 2018-02-17T23:35:49Z

@domenic Thanks for pointing this out; fixed in the new version of the patch.

annevk · 2018-02-18T07:30:31Z

source


 <li><p>If <span data-x="js-Type">Type</span>(<var>value</var>) is Undefined, Null, Boolean,
- String, or Number, then return{[[Type]]: "primitive", [[Value]]: <var>value</var>}.</p></li>
+ String, BigInt, or Number, then return{[[Type]]: "primitive", [[Value]]: <var>value</var>}.</p></li>


Is this the same order that the JavaScript specification will use?

I can't find a list containing these three types in the JavaScript specification. The definition of == contains "String, Number, BigInt, or Symbol" but I didn't really give it any thought when I inserted BigInt in that position.
Should we have a total order of JS primitive types, and whenever we have a list, sort them by that order? What should be this total order? I'd like to defer these advanced editorial questions to the JS spec community's more experienced editorialists, e.g., @jmdyck

I was thinking about the order of the section 6.1 subsections.

Speaking of which, is the fact that we omit Symbol here a bug?

No, it seems we made a decision to throw on symbols. I'm not sure why, but they are quite different from other primitives, so maybe it makes sense.

A: Undefined, Null, Boolean, Number, String, Symbol, Object
B: Undefined, Null, Boolean, Number, Symbol, String
C: Undefined, Null, Boolean, String, Symbol, Number, Object
D: Undefined, Null, Boolean, Number, String, Symbol, Object
E: Undefined, Null, Boolean, Number, String, Symbol, Object
F: Undefined, Null, Boolean, Number, String, Symbol, Object
G: Undefined, Null, Boolean, Number, String, Symbol, Object
H: Undefined, Null, Boolean, Number, String, Symbol, Object
I: Undefined, Null, Boolean, String, Symbol, Number, Object
J: Undefined, Null, Boolean, Number, String, Symbol, Object
So a fair bit of consistency, but also some variation.
About the only benefit I can think of for a consistent order is that it makes it easier to check by eye that some list (set of cases) is complete. Mind you, this benefit would increase as more types are added to the language.
About the only disadvantage I can think of is that if you're doing a case analysis, it might make more sense to the reader to describe the handling of Type X before that for Type Y, and those orderings might not be consistent over the whole spec.

I can't remember from who, but I remember hearing some interest in extending structured clone to Symbols. My impression was that it was left out because it'd be somewhat complicated to make the proper global registry so that if you postMessage the symbol around multiple ways, you get the same one (e.g., sending S from A -> B -> C and also A -> C directly, you'd hope to get the same S').

@jmdyck Where do you think BigInt should be inserted in the list?

Adjacent to Number, presumably, but I'm not sure about before or after.

Let's say BigInt goes after Number, unless someone has a preference otherwise.

annevk · 2018-02-18T07:32:37Z

source


+ <li><p>Otherwise, if <var>value</var> has a [[BigIntValue]] internal slot, then set
+ <var>serialized</var> to{[[Type]]: "BigInt", [[BigIntValue]]: <var>value</var>.[[BigIntValue]]
+ }.</p></li>


I was going to ask about the above aspect here too, but it seems we're already inconsistent in that we put Number before String here...

littledan · 2018-02-18T23:08:54Z

Rearranged to be consistent with the ordering @jmdyck suggested.

Design decisions: - BigInts compare greater than Number and less than everything else - No type coercion between BigInt and Number; they are simply distinct, unrelated keys, even if mathematically equal - No BigInt autoIncrement support--53 bits should be enough for anyone BigInts and BigInt wrappers are proposed to be made serializable, and therefore available as IndexedDB values, in whatwg/html#3480 Addresses w3c#230

domenic · 2018-02-20T20:12:08Z

This looks good to me, although you'll need to add a reference to the BigInt spec similar to https://html.spec.whatwg.org/#import() . (No need for a bulletted list, just a sentence and a bibliography entry.)

We'll also need Igalia to sign the participation agreement.

Finally we'll need multi-implementer interest.

tschneidereit · 2018-02-21T22:07:21Z

Finally we'll need multi-implementer interest.

Just as @annevk said in our BigInt implementation bug, I also think this should happen. In fact it seems entirely obvious to me that it's needed.

ajklein · 2018-02-21T22:14:16Z

Agreed with @tschneidereit, this seems like a straightforward and reasonable thing to do. CC @jakobkummerow @GeorgNeis

littledan · 2018-02-22T11:06:05Z

@domenic

This looks good to me, although you'll need to add a reference to the BigInt spec similar to https://html.spec.whatwg.org/#import() . (No need for a bulletted list, just a sentence and a bibliography entry.)

Thanks for the pointer. It seems like there are a couple things that would make sense to linkify, so I added a bulleted list.

We'll also need Igalia to sign the participation agreement.

Done

Finally we'll need multi-implementer interest.

Does the thread here demonstrate Firefox and Chrome interest?

domenic · 2018-02-22T21:13:49Z

source

+
+ <ul class="brief">
+ <li>The <dfn data-x="js-BigInt" data-x-href="https://tc39.github.io/proposal-bigint/#sec-ecmascript-language-types-bigint-type">BigInt</dfn> type.</li>
+ <li>The <dfn data-x="js-BigIntData" data-x-href="https://tc39.github.io/proposal-bigint/#sec-toobject">[[BigIntData]]</dfn> internal slot</li>


Since we don't link these for other primitives, I don't think we should link them here.

What's the reason that other primitives aren't linked?
I was thinking it could be especially useful to link these, since they relate to a new proposal that people who encounter the spec text may not be familiar with.

Basically to match the JS spec.
I'd rather we stay consistent; we could depart from the JS spec and link everything, but I'd rather do that for everything, not just BigInt.

We could add <ref spec=JSBIGINT> at the end of the lines that use these if we want to give people such a pointer.

Good idea, done.

domenic · 2018-02-22T21:14:21Z

Yeah, all good to go; I'd just like to revert the extra (inconsistent) linkified terms first.

The goal of this PR is to integrate BigInt with HTML serialization. This patch - Adds BigInt to the "safe list" of primitives permitted for serialization. - Adds serialization of BigInt wrappers, analogous to other wrappers. Note that BigInt, like (the unserializable) Symbol does not have a new-able constructor: use of wrappers is explicitly discouraged by the specification. Nevertheless, this patch adds serialization support for consistency with other wrappers. web-platform-tests against postMessage on BigInt are out for review in web-platform-tests/wpt#9565

littledan · 2018-02-23T22:40:24Z

@domenic The current version tries to take your suggestion for references. How does it seem to you?

See whatwg/html#3480.

BigInt and BigInt wrappers are supported in serialization, per whatwg/html#3480 This support allows them to be used as IndexedDB values. However, BigInt is not supported as an IndexedDB key; support has been proposed in the following PR, but that change has not landed at the time this patch was written w3c/IndexedDB#231

…ed clone integration, a=testonly Automatic update from web-platform-testsHTML: add tests to verify BigInt structured clone integration See whatwg/html#3480. wpt-commits: c92168a4fbb507dae4f8caa49ecf0dd6d6bf271e wpt-pr: 9565 wpt-commits: c92168a4fbb507dae4f8caa49ecf0dd6d6bf271e wpt-pr: 9565

BigInt and BigInt wrappers are supported in serialization, per whatwg/html#3480 This support allows them to be used as IndexedDB values. However, BigInt is not supported as an IndexedDB key; support has been proposed in the following PR, but that change has not landed at the time this patch was written w3c/IndexedDB#231

…dDB, a=testonly Automatic update from web-platform-testsTest BigInt as keys and values in IndexedDB (#10977) BigInt and BigInt wrappers are supported in serialization, per whatwg/html#3480 This support allows them to be used as IndexedDB values. However, BigInt is not supported as an IndexedDB key; support has been proposed in the following PR, but that change has not landed at the time this patch was written w3c/IndexedDB#231 -- wpt-commits: b2e3e49410657f7bc8adf42070ddef12ce3761d1 wpt-pr: 10977

…ed clone integration, a=testonly Automatic update from web-platform-testsHTML: add tests to verify BigInt structured clone integration See whatwg/html#3480. wpt-commits: c92168a4fbb507dae4f8caa49ecf0dd6d6bf271e wpt-pr: 9565 wpt-commits: c92168a4fbb507dae4f8caa49ecf0dd6d6bf271e wpt-pr: 9565 UltraBlame original commit: 4bde644e6c99b069f197a274e239ab5152b1bac9

…dDB, a=testonly Automatic update from web-platform-testsTest BigInt as keys and values in IndexedDB (#10977) BigInt and BigInt wrappers are supported in serialization, per whatwg/html#3480 This support allows them to be used as IndexedDB values. However, BigInt is not supported as an IndexedDB key; support has been proposed in the following PR, but that change has not landed at the time this patch was written w3c/IndexedDB#231 -- wpt-commits: b2e3e49410657f7bc8adf42070ddef12ce3761d1 wpt-pr: 10977 UltraBlame original commit: 57ffaa0dbfa1639f73937cf7af08367a466b8eda

…dDB, a=testonly Automatic update from web-platform-testsTest BigInt as keys and values in IndexedDB (#10977) BigInt and BigInt wrappers are supported in serialization, per whatwg/html#3480 This support allows them to be used as IndexedDB values. However, BigInt is not supported as an IndexedDB key; support has been proposed in the following PR, but that change has not landed at the time this patch was written w3c/IndexedDB#231 -- wpt-commits: b2e3e49410657f7bc8adf42070ddef12ce3761d1 wpt-pr: 10977

littledan mentioned this pull request Feb 17, 2018
html: Add tests to verify BigInt structured clone integration web-platform-tests/wpt#9565
Merged

littledan force-pushed the bigint branch from 77c7968 to a187207Compare February 17, 2018 23:35

annevk reviewed Feb 18, 2018
View reviewed changes

annevk added topic: serialize and transfer addition/proposal New features or enhancements labels Feb 18, 2018

littledan changed the title ~~Normative: Permit serialization of BigInt wrappers~~Normative: Permit serialization of BigIntFeb 18, 2018

littledan force-pushed the bigint branch from a187207 to 5374dbfCompare February 18, 2018 18:07

littledan mentioned this pull request Feb 18, 2018
will major browsers support native IndexedDb sorting for BigInt? or will users need to custom-serialize it themselves in sortable form? tc39/proposal-bigint#123
Closed

littledan force-pushed the bigint branch from 5374dbf to 17ff03eCompare February 18, 2018 23:07

littledan mentioned this pull request Feb 18, 2018
Track ES BigInt work w3c/IndexedDB#230
Open

littledan mentioned this pull request Feb 19, 2018
Allow BigInts as IndexedDB keys w3c/IndexedDB#231
Closed

domenic added the needs implementer interest Moving the issue forward requires implementers to express interest label Feb 20, 2018

domenic removed the needs implementer interest Moving the issue forward requires implementers to express interest label Feb 21, 2018

littledan force-pushed the bigint branch from 17ff03e to f0d3238Compare February 22, 2018 11:04

domenic reviewed Feb 22, 2018
View reviewed changes

littledan force-pushed the bigint branch from f0d3238 to 3ca3a7eCompare February 23, 2018 10:39

Fix editorial issues, mostly pre-existing
ff56f34

domenic approved these changes Feb 26, 2018
View reviewed changes

domenic merged commit 01bc5df into whatwg:masterFeb 26, 2018

annevk pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 26, 2018
HTML: add tests to verify BigInt structured clone integration
c92168a
See whatwg/html#3480.

littledan mentioned this pull request Feb 26, 2018
Test BigInt as keys and values in IndexedDB web-platform-tests/wpt#9667
Closed

littledan mentioned this pull request May 8, 2020
Support HTML serialization/structured clone tc39/proposal-temporal#548
Closed

Normative: Permit serialization of BigInt#3480

Normative: Permit serialization of BigInt #3480

Uh oh!

Conversation

littledan commented Feb 17, 2018• edited by pr-preview botLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

domenic commented Feb 17, 2018

Uh oh!

littledan commented Feb 17, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

littledan commented Feb 18, 2018

Uh oh!

domenic commented Feb 20, 2018

Uh oh!

tschneidereit commented Feb 21, 2018

Uh oh!

ajklein commented Feb 21, 2018

Uh oh!

littledan commented Feb 22, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

domenic commented Feb 22, 2018

Uh oh!

littledan commented Feb 23, 2018

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

6 participants

littledan commented Feb 17, 2018•
edited by pr-preview bot
Loading