multiline string should require trailing \

[hax]

It seems current syntax allow multiline string without trailing \, at least in the example

thisAlso: 'is a
multi-line string; but keeps newline'

But it's not valid js, and if allow this, it will break the design goal of "strict subset of JS".

[d3x0r]

\ at the end consumes the newline, flattening the result. Otherwise the newline is kept.

[d3x0r]

Yes; I could have specifically disallowed double and single quoted strings and only allowed it for backtick strings; but there wasn't a lot of benefit for the complexity that added.

[hax]

It have at least one benefit that keep JSON6 as "strict subset of JavaScript" which means you could always paste the whole JSON6 code into JS source file without fear, and you could just eval(JSON6) if do not care about security.

In fact I think "strict subset of JS" is the only reason why JSON or JSON5 or JSON6 could popular than other format. Or why not use yaml ? 😁

[jdalton]

In fact I think "strict subset of JS" is the only reason why JSON or JSON5 or JSON6 could popular than other format. Or why not use yaml ? 😁

I've seen more than one dev nit pick the "strict subset of JS" bit in JSON5 and friends and I always assumed it was devs being pedantic. This is something that could be tweaked, but as long as it's not bugging out someone's code, it's probably fine. I use JSON, or JSON flavors like JSON5 or JSON6, because it's close enough to JS that folks in the JS ecosystem get it. I use yaml, because I'm forced to for other tools, and still don't quite understand all the whitespace and property rules.

[d3x0r]

what issue does this cause you?
conversely to taking this and copying it to javascript, you can take javascript and paste it as JSON6. (minus functions).
If you use underscores in numbers, it will also break pasting into javascript (until proposal is accepted, but even then I allow underscores in places the proposal disallows.

While considering implementing this, was going through the code, and found streaming processing for strings was broken; also some character escapes didn't work very well.

Think anyone will miss octal with just a leading 0 and no o as in 0o ? It's extra work and a minor performance hit (1-2%) to process for the additional case...

[hax]

@jdalton When I mention YAML or other formats, I'm not trying to convince anybody YAML format is better than JSON-like format, at least not in this issue. You can change YAML to any other format for example CSON, TOML, etc. What I'm trying to express is that there are some important factors which make JSON popular, especially JSON is a so anti-human-friendly format. I think “be strict subset of JS” is one of the key factor.

To be honest, I myself am fine with a JSON-like format with a little incompatibility with JavaScript. But I'm sure many will treat such incompatibility as a barrier of adoption, especially you write such commitment is in the README , but actually not follow it.

The simple solution is change the words in the README from “a strict subset of JavaScript” to “a loose subset of JavaScript” or “a superset of JSON/JSON5”. But I still think we can recheck all the incompatibilities to see whether it's useful enough.

What I'm concern is the interoperability of the formats and the tools, parsers for them. We do not want too many branches of JSON-like formats. I could imagine someone fork JSON6 and remove the incompatibilities and release it as JSON7...

but even then I allow underscores in places the proposal disallows.

@d3x0r Yes I was trying to raise this issue too.

It's extra work and a minor performance hit (1-2%) to process for the additional case...

No , I never talk about performance.

---

Besides syntax issues, there are also semantic issues. For example allow undefined, NaN will break the interoperability to JSON/JSON5/YAML or any other format which follow JSON semantic, and it also violate the description of "adds no new data types" in README. But let's focus on syntax problems in this thread.

[d3x0r]

NaN is allowed in Json5.
undefined I have been resconsidering since one way to strip fields is to do JSON.parse( JSON.stringify(thing)). Although the stringify will take care of the field omission. but then again, I've hit that several times when parsing a message that was badly formatted on the other side of a websock connection that had { thing : undefined } because of { thing : ${o.badfield} } .

I'll work on some rewording of the README though.
I started a query on es-discuss... to see if mulltiline support for any quote that could be an addition eventually
https://esdiscuss.org/topic/allow-any-quoted-string-to-be-multiline
probably no hope of that.

[jdalton]

Think anyone will miss octal with just a leading 0 and no o as in 0o ? It's extra work and a minor performance hit (1-2%) to process for the additional case...

Being more correct is a good thing. The minor perf hit can be offset or mitigated I'm sure.

[d3x0r]

'being more correct' javascript itself doesn't take 0123 as octal... Only 0o123.
although many other languages do take octal with leading 0 on a decimal number.... is that 'correct' ?

[jdalton]

By more correct I mean following the language precedents and specification when possible.

[hax]

NaN is allowed in Json5.

Yes, there was an old issue: json5/json5-spec#2

The author of JSON5 said

The reason I feel that JSON5 needs to maintain backward compatible serialization with JSON is because I think JSON5 should be to JSON what Babel and CoffeeScript are to JavaScript—syntactic sugar. In other words, JSON5 transpiles to JSON.

As this rule (can transpile to JSON), ±Infinity is ok because JSON.parse('1e99999') return +Infinity so it's easy to keep compatibility. But NaN is problematic which have no JSON equivalent representation.

[d3x0r]

and that was closed with ... "Leaving Infinity and NaN as is for now."
some compelling arguments there...
however, this isn't GON (or general object notation), but JS for Javascript, therefore, I feel it should support what javascript can. Which, when implementing it in C, did make me go dig for how to represent NaN and Infinity in a portable way; which I guess I ended up deciding I didn't have to do... leaving instead the value structure with a .type set to VALUE_NAN or VALUE_NEG_NAN or inifniity respectively.

Updated documenation...
"JSON6 is a superset of JavaScript, although adds no new data types, and works with all existing JSON content. Some features allowed in JSON6 are not directly supported by Javascript; although all javascript parsable features can be used in JSON6, except functions or any other code construct, transporting only data save as JSON."

https://github.com/d3x0r/json6#caveats

"Objects can have a single trailing comma. Excessive commas in objects will cause an exception. '{ a:123,,b:456 }' is invalid."

Reverted const SUPPORT_LEAD_ZERO_OCTAL = true; to support leading 0 octal interpretations.