Re: [heycam/webidl] Add bigint type (#525)

WebIDL has a number of cases where it switches among all of the JS primitive types. If BigInt is a type in JavaScript, maybe we should have some description or other of what the behavior is when a BigInt ends up floating into certain operations, such as [converting an ES value to any](https://heycam.github.io/webidl/#es-any), even if we want to wait until we have more information to decide how to define what it means to overload with a `bigint` type.

One place BigInt will come up is the WebAssembly-JS API. If the [proposed BigInt/i64 integration](https://github.com/WebAssembly/spec/pull/707) is combined with the [proposed WebAssembly.Global](https://github.com/WebAssembly/mutable-global) interface, then I think we'd want to say that the type of the WebAssembly.Global.prototype.valueOf method is `bigint or unrestricted double`, for example. But maybe we could define something special in prose in that particular document, without updating WebIDL so generally.

Besides that, I don't have a particular other web platform feature that where I want to propose BigInt usage. All the examples I can think of (constant time 64-bit arithmetic operations, a date format representing time in nanoseconds since forever ago, etc) might make more sense in the JavaScript standard itself than as WebIDL-based APIs. Like the IndexedDB integration, I'm fine waiting until we have more motivation for this change.

As much as it's appropriate to wait for more applications to get input for the design of the BigInt WebIDL binding, I wanted to document a suggestion for best practices here, at least from the perspective of the way BigInt was designed in JavaScript, in particular, avoiding implicit conversions that lose information, and continuing to use Number exclusively everywhere it is currently used in WebIDL.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/525#issuecomment-370043468