JSON support for BigInt in Chrome/V8
kaizhu256 at gmail.com
Thu Jul 19 21:43:40 UTC 2018
reposting due to previous mail-rejection (vpn issue with gmail in china)
>You already can't use `new` with `Symbol`, and you don't ever want to use `new` with a primitive's constructor anyways.
this rule would be *okay* if we limit the number of primitive-types in
the language to a small-number (maybe add BigDecimal, but that's it),
so its easy to remember. i'm already concerned that we have one too
many needless primitives (Symbol should've been an object similar to
Promise, and even more so since its use-case is marginal).
adding more primitives at this point, will only make this
pedantic-rule look more like a wart, and trip-up beginners (and their
prejudice on the language's inconsistencies). it also complicates
integration-work on web-projects, due to difficulty baton-passing new
primitives around via JSON, and having to continually refactor
type-checks that rely on typeof.
On 7/17/18, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> fair enough, so everything that is not `object` or `null` should never use
> `new`. Is this somehow an indirect rule based on current specs or actually
> part of the specification?
> On Tue, Jul 17, 2018 at 11:12 AM J Decker <d3ck0r at gmail.com> wrote:
>> On Tue, Jul 17, 2018 at 1:48 AM Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>> We miss a fundamental feature in JS, the ability to understand if a
>>> native constructor can be used with `new` or not.
>>> new BigInt("5555555555555555555555555500003");
>>> VM51:1 Uncaught TypeError: BigInt is not a constructor
>>> VM54:1 Uncaught TypeError: Constructor Uint8Array requires 'new'
>>> new Uint8Array()
>>> Uint8Array 
>>> Without that knowledge, any attempt to even think about a solution that
>>> would scale not only with BigInt but with everything else, is kinda
>>> Best Regards.
More information about the es-discuss