Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BigInt Shipping in Firefox

wingolog.org

Post reply on HN
Print view View original

71–80 of 172 posts

Re: BigInt Shipping in Firefox

#71

Post by dlbucci »

hombre_fatal wrote: post #57
dlbucci wrote: post #43

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with nu…

By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint. But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.

I don't know if that follows. I think it's reasonable to expect a piece of code that works with integer numbers to also work with bigints. But it's not really reasonable to expect it to work with anything that closely resembles a number. That sort of weak typing is much more problematic and should be avoided.

But I dunno, maybe it shouldn't be expected to work with bigints either. It's not a regular int, so I doubt people will start using these as array indices in for loops or what have you, so maybe it should be a different type...

Re: BigInt Shipping in Firefox

#73

Post by acdha »

anoncake wrote: post #38
acdha wrote: post #13

Earlier quoted context omitted.

Yeah, the Chrome team basically recommended not to, favoring using something like Babel instead: https://developers.google.com/web/updates/2018/05/bigint#pol...

> and they are also making it infeasible (in most cases) to transpile BigInt code to fallback code using Babel or similar tools. That doesn't sound like a recommendation.

Note the comma: I was specifically referring to the advice against attempting to polyfill it. The Babel reference was attempting to convey the idea that instead you need something on the same order of complexity as a compiler to do this properly, but the details about JSBI are why I linked to their writeup rather than trying to summarize it.

Re: BigInt Shipping in Firefox

#75

Post by kibwen »

RHSeeger wrote: post #74
ghettoimp wrote: post #64

Earlier quoted context omitted.

I like your haiku. But stay away from TCL... It is such a mess.

I love TCL, personally. It's my favorite language to play around in.

Fixed it for you:

> I love TCL.

> It's my favorite language

> to play around in.

Re: BigInt Shipping in Firefox

#76

Post by hombre_fatal »

dlbucci wrote: post #71
hombre_fatal wrote: post #57

Earlier quoted context omitted.

By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint. But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.

I don't know if that follows. I think it's reasonable to expect a piece of code that works with integer numbers to also work with bigints. But it's not really reasonable to expect it to work with anything that closely resembles a number. That sort of weak typing is much more problematic and should be avoided. But I dunno, maybe it shouldn't be expected to work with bigints either. It's not a regular int, so I doubt p…

But it's really not. Pretty major difference between floats and arbitrary precision, like how you'll get different arithmetic results passing in 42 vs 42n. Just like any language that doesn't let you mix float and integer operands. Also, what's even the return value?

You need to make a deliberate decision about your data, not deck the halls with just-in-case programming. The software you write will be much better for it.

Besides, even if you could justify a bunch of typeof checks and you were doing it everywhere, Javascript already has a way to spare you from repetitive code: a function.

Re: BigInt Shipping in Firefox

#77

Post by hombre_fatal »

jfk13 wrote: post #68
tzs wrote: post #45

Earlier quoted context omitted.

How about serializing to an array ["bigint", "170141183460469231731687303715884105727"]? It takes more space, but is easy to recognize, and easy to generalize to other types.

Presumably that could be confusing if you ever happen to have an actual array whose first element is the string "bigint".

Well, no matter what you do, surely you plan on documenting your API to such a bare bones level that your user isn't racking their brain whether a key is a number or an array of data.

Re: BigInt Shipping in Firefox

#78

Post by cpeterso »

BitInt's "n" suffix appears to stand for "numeric", but that seems confusing when typeof 1 === "number" and typeof 1n === "bigint". Why not an "i" suffix for "integer"? I understand that a "b" suffix is probably reserved in case JavaScript adds support for binary literals.

https://tc39.github.io/proposal-bigint/#prod-BigIntLiteralSu...

Re: BigInt Shipping in Firefox

#79

Post by recursive »

dlbucci wrote: post #71
hombre_fatal wrote: post #57

Earlier quoted context omitted.

By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint. But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.

I don't know if that follows. I think it's reasonable to expect a piece of code that works with integer numbers to also work with bigints. But it's not really reasonable to expect it to work with anything that closely resembles a number. That sort of weak typing is much more problematic and should be avoided. But I dunno, maybe it shouldn't be expected to work with bigints either. It's not a regular int, so I doubt p…

Well, bigints are fine as array indices. However they are not interoperable with numbers in any type of arithmetic. I don't think it's reasonable to expect to use bigints in any place where one uses numbers.

"Regular int" is not a distinct type in javascript. There are now two numeric types: 64-bit floating point, and bigint.

Re: BigInt Shipping in Firefox

#80

Post by bufferoverflow »

derfniw wrote: post #50
bpye wrote: post #39

Earlier quoted context omitted.

You can certainly serialize to a string but knowing when you should revive to a BigInt seems tricky. You could prefix the strings I guess?

Reuse the literal? (postfix with 'n')

You don't want strings that are "digits..n" to automatically deserialize into bigints. What if you have a string like "8n", which is a tractor model, or "9n", which is a smartphone model?

But it would be nice to have literal 8n to convert to a bigint 8n. That's not in the JSON standard though.

Post reply on HN