proposal-number-fromstring

proposal-number-fromstring copied to clipboard

I asked @mathiasbynens if there was a BigInt.from and was asked to file an issue here. I suggested it because I know of Array.from.

Looking at https://web-confluence.appspot.com/#!/catalog?releases=%5B%22Safari_11.1_OSX_10.13.4%22,%22Edge_17.17134_Windows_10.0%22,%22Chrome_70.0.3538.67_Windows_10.0%22,%22Firefox_62.0_Windows_10.0%22%5D&q=%22from%22, it seems Array and related classes are the only ones on the web platform with just from as the converted function, various fromX are more common.

If anyone's very curious, what I wanted to do was to convert a Git 160-bit SHA-1 to something I could use as a key in a Map. I ended up just living with using 4x the memory by using the 40 code point hex representation. One can also encode it as 10 code points.

I would expect BigInt.from to behave the same way as BigInt constructor but more "permissive" in its syntax and accepted types and values, but no support for radices/bases. That's just my opinion, it may be wrong

using 4x the memory by using the 40 code point hex representation. One can also encode it as 10 code points.

That's a hack I learned when using "Automate". Both JS and AM allow (but discourage) the use of "binary strings", where each UTF-16 code-unit encodes 1 octet of data.

But what many people don't know, is that neither JS, nor AM, nor Java, forbid invalid surrogate-pairs, this means we can use the full 2 bytes of memory allocated by each code-unit in a string, essentially being 4x more efficient than hex. This way, the string becomes an array of u16s instead of the usual u8 array.

I expected engines to be smart enough to detect binary strings (or any ASCII-exclusive string) and reduce memory use by allocating a u8[], similarly to how float64s are optimized as u32s when possible