On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
> In my opinion we should follow the formal JSON grammar.

This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.

On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote:
> On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
>> In my opinion we should follow the formal JSON grammar.
>
> This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.

Then my reading says this really _is_ a bug. At least, according to http://www.ietf.org/rfc/rfc4627.txt, which states and shows only that:
"Insignificant whitespace is allowed before or after any of the six structural characters."

..unless there's a different version that supersedes that one?

-Wyatt

On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote:
> On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
>> In my opinion we should follow the formal JSON grammar.
>
> This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.

Exactly. Here's the official web page complete with nice graphics detailing the grammar: http://json.org/. I've read the JSON RFC before, but I can't remember what it says about whitespace within a basic value, but the graphics here make it very clear that whitespace does *not* belong inside a value.

The real question is, is this worth fixing before std.serialize makes it in? There will likely be other bugs once/if that's accepted. I tried extending std.json in the past with static reflection, but that didn't make it in for this very reason.

> The real question is, is this worth fixing before std.serialize makes it in? There will likely be other bugs once/if that's accepted. I tried extending std.json in the past with static reflection, but that didn't make it in for this very reason.

Yep no one seems to care about std.json.

On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote:
> On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
>> In my opinion we should follow the formal JSON grammar.
>
> This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.

A formal grammar can be found here starting on page 202 but I don't know enough about grammars to be able to interpret it.
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

Im starting to become less sure if its a bug or not...

On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote:
> On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
>> In my opinion we should follow the formal JSON grammar.
>
> This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.

I agree with Dicebot. I posted on the other thread for JSON real numbers and explained why it isn't a bug.

On Thu, 08 Aug 2013 17:17:38 +0200
"Tofu Ninja" <emmons0@purdue.edu> wrote:

> On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote:
> > On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
> >> In my opinion we should follow the formal JSON grammar.
> >
> > This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.
> 
> A formal grammar can be found here starting on page 202 but I
> don't know enough about grammars to be able to interpret it.
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
> 
> Im starting to become less sure if its a bug or not...

I think that makes it clear that whitespace is NOT allowed within numeric or fractional literals. Note that the JSONNumber and JSONFraction tokens are defined in the lexical section (15.12.1.1). In a lexer, whitespace is something that is always handled explicitly (as they do, in both the JSONWhiteSpace and JSONStringCharacter tokens).

Down in the "Syntactic Grammar" section (15.12.1.2), they don't explicitly mention anything about whitespace (for example, in the JSONElementList token, where we already *know* whitespace is allowed). This is undoubtedly because (aside from lexing) whitespace is generally NOT explicit, but rather implied to optionally exist before/after each token.

It sounds like the bug is that std.json is currently treating JSONNumber (and maybe JSONFraction too) as a parser-handled nonterminal, instead of a lexer-handled terminal as the spec indicates.

On Thursday, 8 August 2013 at 15:17:40 UTC, Tofu Ninja wrote:
> A formal grammar can be found here starting on page 202 but I don't know enough about grammars to be able to interpret it.
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
>
> Im starting to become less sure if its a bug or not...

I don't recogise that exact BNF notation (single colon? New to me.), but unless it's fairly...unique, it's still a bug according to a strict reading.  (I feel the RFC version is somewhat more clear, honestly.)

-Wyatt

On Thursday, 8 August 2013 at 15:15:44 UTC, David wrote:
>> The real question is, is this worth fixing before std.serialize makes it
>> in? There will likely be other bugs once/if that's accepted. I tried
>> extending std.json in the past with static reflection, but that didn't
>> make it in for this very reason.
>
> Yep no one seems to care about std.json.

I heard about std.xml being crap and was going to use std.json, then I ran into this thread.

So what should one use to parse json, or xml for that matter?

On Thursday, 8 August 2013 at 16:26:40 UTC, Lemonfiend wrote:
> On Thursday, 8 August 2013 at 15:15:44 UTC, David wrote:
>>> The real question is, is this worth fixing before std.serialize makes it
>>> in? There will likely be other bugs once/if that's accepted. I tried
>>> extending std.json in the past with static reflection, but that didn't
>>> make it in for this very reason.
>>
>> Yep no one seems to care about std.json.
>
> I heard about std.xml being crap and was going to use std.json, then I ran into this thread.
>
> So what should one use to parse json, or xml for that matter?

There are several JSON implementations floating around, I personally prefer vibe.d one - https://github.com/Dicebot/vibe.d/blob/master/source/vibe/data/json.d

For XML Tango module is often mentioned as most awesome one - https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/text/xml