This would be the correct understanding here, a 4th parameter read as a boolean.
On Sun, Oct 21, 2018 at 12:27 Peter Jaszkowiak <[email protected]> wrote: > He was recommending a single parameter for "parse ints as bigints", not > changing the default behavior. > > On Sun, Oct 21, 2018, 09:58 Richard Gibson <[email protected]> > wrote: > >> First, note that reviver functions *do* manipulate the result after it's >> parsed. Second, "parse ints as bigints" is too big a hammer—changing the >> output for all numbers would break currently working code. And third, it's >> not even fully sufficient for the "big numbers" purpose, which logically >> also includes non-integers outside the IEEE 754 64-bit range ("BigFloat"). >> >> On Sun, Oct 21, 2018 at 10:50 AM Isiah Meadows <[email protected]> >> wrote: >> >>> Just because something exists doesn't mean it'll be broadly used. Plus, >>> reviver functions are normally incredibly simple - you don't get enough >>> context (like key paths) to do anything crazy, and this proposal doesn't >>> give you enough context for that. >>> >>> In practice, this changes literally nothing for most consumers, since >>> the use case is incredibly limited and usually requires server agreement as >>> well. In fact, that's where my skepticism lies: why add 3 new reviver >>> parameters when a single "parse ints as bigints" would solve basically the >>> entire problem? I've yet to see any other use case that couldn't be solved >>> by manipulating the result after it's parsed. >>> >>> But personally, I don't see how bugs would be a major issue here >>> considering its limited utility. >>> >>> On Sun, Oct 21, 2018 at 02:01 kai zhu <[email protected]> wrote: >>> >>>> wish to express skepticism for the stage-1 proposal "JSON.parse source >>>> text access" [1], from web-integration perspective. >>>> >>>> a common javascript-painpoint is pinpointing bug-source of end-to-end >>>> client<->server communications. thankfully, JSON.parse is rarely suspect >>>> in this process. this proposal however, encourage developers to introduce >>>> bugs/doubts-of-reliability to JSON.parse, making integration bug-hunting >>>> more painful than it already is. >>>> >>>> standard-operating-procedure for reviving JSON-data is a 2-step process: >>>> 1. JSON.parse with zero-config to rule-out bugs during this step >>>> 2. second-pass of plain-JSON to revive [product-specific] >>>> string-encoded non-JSON datatypes like BigInt/Date/RegExp, where bugs >>>> can be expected >>>> >>>> you normally do not want to complicate bug-hunts by contaminating >>>> step-1 with bugs from step-2. >>>> >>>> [1] stage-1 proposal - JSON.parse source text access >>>> https://github.com/gibson042/ecma262-proposal-JSON-parse-with-source >>>> >>>> kai zhu >>>> [email protected] >>>> >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
