[jfoutz]

There is an intrinsic order in the text though. it's up to the parser to keep clobbering a value every time a new value comes in for a given key.

This seems like a bad idea. It seems heavily reliant on edge case behavior. But hey, might work well for the original author.

[IanCal]

> it's up to the parser to keep clobbering a value every time a new value comes in for a given k

Nope, parsers are perfectly in their rights to do whatever they want with multiple keys. They could read them backwards, sort them, whatever. The behaviour in the instance of multiple keys is undefined.

> This seems like a bad idea.

It is an astonishingly bad idea. I'm concerned by it being so high on the page.

> But hey, might work well for the original author.

Depends on their parser. It's undefined behaviour according to the spec. It might work now, but I'd argue it doesn't work well, as a patch level change could bork this.

[jfoutz]

I'm not so sure. I think, JSON falls back to the ecma script standard for specific details. The object initializer semantics seem to force a left to right evaluation order, in the ecma spec around page 65. I'll admit my claim was unfounded when i made it, and I only went to the spec to avoid being wrong :) If I were to implement a JSON parser, I would now feel obligated to eval in order, due to my reading of the spec.

However, I think we wholeheartedly agree, don't rely on this behavior. It is an outright strict mode error.