Closed kenchris closed 4 years ago
Parsing should throw on the empty byte sequence, no? I'm not sure why we'd require a non-throwing input. We'd have to modify a bunch of callers if we'd decide to do that.
For serialization I'm not sure it makes sense to return the empty byte sequence, as that's not valid JSON. I'd be somewhat inclined to throw as well, though not entirely sure what exception.
So JSONparse has this
But not sure what toString would be called with when there is an empty byte sequence? (null or undefined?)
I'd be somewhat inclined to throw as well, though not entirely sure what exception.
SyntaxError seems consistent with the above
@kenchris jsonText is not a byte sequence, we pass that function a string.
Right, we just need to handle 0 bytes ourselves, as UTF8Encode of 0 bytes makes no sense.
I'm not sure I understand, the parser decodes and decoding the empty byte sequence works fine.
OK, what does it decode it to? @zolkis and I found it hard following the algorithms in the encoding spec
To an empty code point stream, which can be coerced automatically into a string.
Looking at this, it seems like there's still an issue with the call to %JSONStringify%
being able to return undefined
. Presumably the operation should throw in that case, so any result of serialization can round-trip.
Additionally, there should probably be a note indicating that those operations can throw, and that serialize can execute user code and cause side effects.
Round-tripping is not necessarily a goal. And undefined is a valid stringification, if you pass it undefined.
undefined
may be a valid stringification in Javascript land, but here Infra proceeds to UTF-8 encode it, which is not valid. And I wasn't talking so much about round-tripping of Infra values as that the output of serialization doesn't throw when deserialized.
JSON.stringify
can return undefined if called with things likeundefined
orSymbol('mySymbol')
This should result in 0 bytes (null) being the result of the algorithm. We can of course also just make it return an error and handle it elsewhere
deserialization should probably also assert that there is actually a non-zero length byte sequence