Allow BigInts as IndexedDB keys by littledan · Pull Request #231 · w3c/IndexedDB (original) (raw)
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 #230
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 number or date, |
| a {{DOMString}} if type is string, |
| a list of {{octet}}s if type is binary, |
| an integer if the type is bigint, |
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.
littledan added a commit to littledan/webidl that referenced this pull request
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
littledan added a commit to littledan/webidl that referenced this pull request
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
littledan added a commit to littledan/webidl that referenced this pull request
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
littledan added a commit to littledan/webidl that referenced this pull request
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
littledan added a commit to littledan/webidl that referenced this pull request
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
littledan added a commit to littledan/web-platform-tests that referenced this pull request
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.
littledan added a commit to littledan/webidl that referenced this pull request
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.
inexorabletash pushed a commit to web-platform-tests/wpt that referenced this pull request
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
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request
…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 any for these operations?
#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.