Normative: Extend JSON.parse and JSON.stringify for interaction with the source text of primitive values #3714
Conversation
…the source text of primitive values
|
The rendered spec for this PR is available at https://tc39.es/ecma262/pr/3714. |
ljharb
added
normative change
spec.html
Outdated
| <p>The `rawJSON` function returns an object representing raw JSON text of a string, number, boolean, or null value.</p> | ||
| <emu-alg> | ||
| 1. Let _jsonString_ be ? ToString(_text_). | ||
| 1. Throw a *SyntaxError* exception if _jsonString_ is the empty String, or if either the first or last code unit of _jsonString_ is any of 0x0009 (CHARACTER TABULATION), 0x000A (LINE FEED), 0x000D (CARRIAGE RETURN), or 0x0020 (SPACE). |
There was a problem hiding this comment.
I noticed that we never use in algorithms the structure "Throw a exception if ", it's usually "If , throw a exception."
There was a problem hiding this comment.
We did prior to #3540, when this text was originally written, but yeah we've done away with that now.
There was a problem hiding this comment.
Fixed, and added tighter assertions.
| 1. Let _internalSlotsList_ be « [[IsRawJSON]] ». | ||
| 1. Let _obj_ be OrdinaryObjectCreate(*null*, _internalSlotsList_). |
There was a problem hiding this comment.
Any reason for not inlining _internalSlotsList_, like we do in most OrdinaryObjectCreate calls where we pass extra slots?
There was a problem hiding this comment.
We've got examples of both, and I personally like having the name as an explicit hint of semantics for an otherwise opaque list of slot references, but am willing to inline it if that's the consensus preference among editors.
spec.html
Outdated
| 1. Else, | ||
| 1. Assert: _typedValNode_ is an |ObjectLiteral| Parse Node. | ||
| 1. Let _propertyNodes_ be PropertyDefinitionNodes of _typedValNode_. | ||
| 1. NOTE: Because _val_ was produced from JSON text and has not been modified, all of its property keys are Strings and will be exhaustively enumerated in source text order. |
There was a problem hiding this comment.
Is this true? In Object.keys({ "a": 1, "0": 2 }) they are not enumerated in source text order.
There was a problem hiding this comment.
Nice catch! I removed the "in source text order" part of the note, which isn't important anyway.
…n with the source text of primitive values
…n with the source text of primitive values
…n with the source text of primitive values
4 participants
This implements JSON.parse source text access, currently at stage 3. Tests have already been merged, but might still be extended.