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
