-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow BigInts as IndexedDB keys #231
Conversation
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
@@ -622,6 +637,7 @@ be either: | |||
an {{unrestricted double}} if type is <i>number</i> or <i>date</i>, | |||
a {{DOMString}} if type is <i>string</i>, | |||
a list of {{octet}}s if type is <i>binary</i>, | |||
an integer if the type is <i>bigint</i>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is a little fudge--the other types have meanings that are more well-defined in terms of Infra or WebIDL, but there isn't a BigInt WebIDL type yet.
Thanks for the PR! To set expectations: • We haven't kicked off 3.0 yet, and this should probably block on that. • We'd like one implementation (even nightly build/behind a flag) before merging. • Need web-platform-test coverage, ideally landed first. |
OK, I don't have time to implement this right now, and I'm not sure if any implementers are interested. If anyone is interested, please respond here and I can write some web-platform-tests. Otherwise, we can consider this a fun thought exercise. |
This patch adds a bigint type to WebIDL with the following properties: - bigint corresponds directly to BigInt - The conversion from JS is based on ToBigInt, namely it throws on Number. - bigint is not grouped as a "numeric" type, as this category is often used to refer to types which have a JavaScript representation of Number. - bigint is included in the overloading resolution algorithm, and it's possible to overload a function for BigInt and numeric arguments. Although it may be on the early side for such a change, the lack of BigInt WebIDL integration is already coming up in some designs for integrating BigInt with the Web Platform, such as w3c/IndexedDB#231
This patch adds a bigint type to WebIDL with the following properties: - bigint corresponds directly to BigInt - The conversion from JS is based on ToBigInt, namely it throws on Number. - bigint is not grouped as a "numeric" type, as this category is often used to refer to types which have a JavaScript representation of Number. - bigint is included in the overloading resolution algorithm, and it's possible to overload a function for BigInt and numeric arguments. - bigint constants are provided with syntax analogous to JS. Although it may be on the early side for such a change, the lack of BigInt WebIDL integration is already coming up in some designs for integrating BigInt with the Web Platform, such as w3c/IndexedDB#231
This patch adds a bigint type to WebIDL with the following properties: - bigint corresponds directly to BigInt - The conversion from JS is based on ToBigInt, namely it throws on Number. - bigint is not grouped as a "numeric" type, as this category is often used to refer to types which have a JavaScript representation of Number. - bigint is included in the overloading resolution algorithm, and it's possible to overload a function for BigInt and numeric arguments. - bigint constants are provided with syntax analogous to JS. - bigint is included in the es-to-union algorithm. For good measure, symbol is added as well (it appears to have been missing). Although it may be on the early side for such a change, the lack of BigInt WebIDL integration is already coming up in some designs for integrating BigInt with the Web Platform, such as w3c/IndexedDB#231
This patch adds a bigint type to WebIDL with the following properties: - bigint corresponds directly to BigInt - The conversion from JS is based on ToBigInt, namely it throws on Number. - bigint is not grouped as a "numeric" type, as this category is often used to refer to types which have a JavaScript representation of Number. - bigint is included in the overloading resolution algorithm, and it's possible to overload a function for BigInt and numeric arguments. - bigint constants are provided with syntax analogous to JS. - bigint is included in the es-to-union algorithm. Although it may be on the early side for such a change, the lack of BigInt WebIDL integration is already coming up in some designs for integrating BigInt with the Web Platform, such as w3c/IndexedDB#231
This patch adds a bigint type to WebIDL with the following properties: - bigint corresponds directly to BigInt - The conversion from JS is based on ToBigInt, namely it throws on Number. - bigint is not grouped as a "numeric" type, as this category is often used to refer to types which have a JavaScript representation of Number. - bigint is included in the overloading resolution algorithm, and it's possible to overload a function for BigInt and numeric arguments. - bigint constants are provided with syntax analogous to JS. - bigint is included in the es-to-union algorithm. Although it may be on the early side for such a change, the lack of BigInt WebIDL integration is already coming up in some designs for integrating BigInt with the Web Platform, such as w3c/IndexedDB#231
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
It's rather circumstantial evidence, but I'm seeing not so much expression of people saying they would actually use BigInt as IndexedDB keys in this Twitter poll. By contrast, there was a lot more interest in BigInt64 TypedArrays. |
This patch adds a bigint type to WebIDL with the following properties: - bigint corresponds directly to BigInt - The conversion from JS is based on ToBigInt, namely it throws on Number. - bigint is not grouped as a "numeric" type, as this category is often used to refer to types which have a JavaScript representation of Number. - bigint is included in the overloading resolution algorithm, and it's possible to overload a function for BigInt and numeric arguments. - bigint constants are provided with syntax analogous to JS. - bigint is included in the es-to-union algorithm. Although it may be on the early side for such a change, the lack of BigInt WebIDL integration is already coming up in some designs for integrating BigInt with the Web Platform, such as w3c/IndexedDB#231
i'm just conjecturing, if the twitter poll was re-worded "Should BigInt64 be supported as an IndexedDB key?" it may get the same enthusiasm as BigInt64 TypedArrays. also keep in mind the potential impact to indexeddb from introduction of future javascript data-types under discussion (e.g. bigdecimal and complex-numbers). |
@kaizhu256 I don't know what that would mean--BigInt64 isn't a thing. Anyway, there's a clear majority of non-don't-care respondents who supported it as a key, just that only a small minority said they would use it themselves. |
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
…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 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 UltraBlame original commit: 57ffaa0dbfa1639f73937cf7af08367a466b8eda
@inexorabletash @asutherland any reason we're not doing this? This isn't blocked on IDL right as you're using #231 (comment) perhaps? If so, maybe we should make that clear by closing this. |
It's a reasonable enhancement for completeness, but adding new type support to keys implies potentially non-trivial enhancements to whatever the implementation is using for comparator/ordering purposes. Given #231 (comment) this does seem like a high cost/benefit ratio compared to other implementation and spec concerns. |
FWIW, we've had no requests come through our bug channels or from partners. |
I'm going to close this then for clarity. Hope that's okay. |
Design decisions:
distinct, unrelated keys, even if mathematically equal
BigInts and BigInt wrappers are proposed to be made serializable, and
therefore available as IndexedDB values, in
whatwg/html#3480
Addresses #230