[MatthewPhillips]

That example is fine, but you wouldn't want a long comment getting loaded into memory because the parser doesn't know any better.

[dnautics]

for that matter, just do:

{

  "comment":"this is a comment";
  "value": 45;

  "comment":"this is also a comment";
  "value2": 64;

  "comment":"we like overloading the comment field";
  "stringval":"but these stay the same";

}

[IanCal]

Then the parser might fail, and rightly so. A comment lower down shows it failing in a simple parser in go: https://news.ycombinator.com/item?id=6147478

Keys SHOULD be unique.

[dnautics]

SHOULD != SHALL

And, no, this scheme doesn't break the go parser because there isn't a typeshift between the "comment" fields, they are all strings.

http://play.golang.org/p/bxcIIyAeph

[IanCal]

Ah fair enough on the break, I was wrong there.

But if the spec says that keys SHOULD be unique, what's the behaviour when they aren't?

[dnautics]

I would agree it's very hackey and probably not a good idea since the spec is liable to change. But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments.

[IanCal]

> I would agree it's very hackey and probably not a good idea since the spec is liable to change

Well it's not really about the spec changing, the spec doesn't have a defined behaviour for duplicate keys.

> But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments.

I don't think duplicate keys should be allowed, but I've no strong feelings on comments. I don't think there's any real need for them though.

[kstenerud]

Why not? It's just a configuration file.