Am 26.08.2014 12:00, schrieb ketmar via Digitalmars-d:
> On Tue, 26 Aug 2014 09:32:09 +0000
> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Are the drawbacks of JSON so big? Why to move away from it
> i don't know too. i think that it's enough to add three features to
> current json parser to be happy:
> 1. comments, both '//' and '/* */.
> 2. unquoted field names.
> 3. ignoring trailing commas.
>
> ah, optional 4th feature: allow omiting highest-level curly brackets.
>
> this additions will not break any existing json definitions, but allow
> us to use some human-friendly features.
>

I agree. Those would be the points with most impacts. However, the outcome would be quite far away from standard JSON, so we would really be talking about something like ASON or SDL already.

On Tue, 26 Aug 2014 12:20:55 +0200
Sönke Ludwig via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I agree. Those would be the points with most impacts. However, the outcome would be quite far away from standard JSON, so we would really be talking about something like ASON or SDL already.
most widely-used json parsers supports that three features anyway, i believe, so it's almost safe to just add 'em.

yes, we can have other backends -- xml, ason, sdl, anything. but i can't see any sane reasons to add such backends. they will lead to code bloating, more testing and will just confuse end-users ("oh, which backend i should use? why there are so many?").

On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 26 Aug 2014 09:32:09 +0000
> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Are the drawbacks of JSON so big? Why to move away from it
> i don't know too. i think that it's enough to add three features to
> current json parser to be happy:
> 1. comments, both '//' and '/* */.

Not exactly that, but look here two approaches for introducing comments in standard JSON:

1: a convention

http://stackoverflow.com/a/244858


2: a hack

http://fadefade.com/json-comments.html

On Tuesday, 26 August 2014 at 10:20:53 UTC, Sönke Ludwig wrote:
> Am 26.08.2014 12:00, schrieb ketmar via Digitalmars-d:
>> On Tue, 26 Aug 2014 09:32:09 +0000
>> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>

> I agree. Those would be the points with most impacts. However, the outcome would be quite far away from standard JSON, so we would really be talking about something like ASON or SDL already.

There are some beginnings like this one:

http://json5.org/

On Tuesday, 26 August 2014 at 10:20:53 UTC, Sönke Ludwig wrote:
> Am 26.08.2014 12:00, schrieb ketmar via Digitalmars-d:
>> On Tue, 26 Aug 2014 09:32:09 +0000
>> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I agree. Those would be the points with most impacts. However, the outcome would be quite far away from standard JSON, so we would really be talking about something like ASON or SDL already.

Anyway, if moving away from JSON is a must, and SDL will be good enough, the I would vote for it.

On Tue, 26 Aug 2014 10:36:14 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Not exactly that, but look here two approaches for introducing comments in standard JSON:
they both 'hacks'. and i'm pretty sure that most people who using JSON never bother to read specs, they just expect it to work "like javascript". i myself wasn't aware about JSON limitations when i was writing my own JSON parser, so my parser allows comments and unquoted field names from the beginning.

i'm still sure that JSON specs are needlessly strict in some areas, and specs should include comments from the start...

On Tuesday, 26 August 2014 at 10:36:15 UTC, eles wrote:
> On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via Digitalmars-d wrote:
>> On Tue, 26 Aug 2014 09:32:09 +0000
>> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>> Are the drawbacks of JSON so big? Why to move away from it
>> i don't know too. i think that it's enough to add three features to
>> current json parser to be happy:
>> 1. comments, both '//' and '/* */.
>
> Not exactly that, but look here two approaches for introducing comments in standard JSON:
>
> 1: a convention
>
> http://stackoverflow.com/a/244858
>
>
> 2: a hack
>
> http://fadefade.com/json-comments.html

These are mostly useful for documentation comments, but not so much for disabling parts of the definitions temporarily, which would be my primary use case.

On Tuesday, 26 August 2014 at 11:19:34 UTC, Marc Schütz wrote:
> On Tuesday, 26 August 2014 at 10:36:15 UTC, eles wrote:
>> On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via Digitalmars-d wrote:
>>> On Tue, 26 Aug 2014 09:32:09 +0000
>>> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> These are mostly useful for documentation comments, but not so much for disabling parts of the definitions temporarily, which would be my primary use case.

Yes, I missed that. Good point.

On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
> The fact that it's backwards compatible with JSON would be useful for avoiding breaking existing dub packages, and it does sound like it's a better format, but the fact that it's just been created for this makes me leery.

Well, formats are created if existing formats are suboptimal. JSON is not a general-purpose format, it was designed to be locked on javascript parsers.

On Tuesday, 26 August 2014 at 13:28:28 UTC, Kagamin wrote:
> On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
>> The fact that it's backwards compatible with JSON would be useful for avoiding breaking existing dub packages, and it does sound like it's a better format, but the fact that it's just been created for this makes me leery.
>
> Well, formats are created if existing formats are suboptimal. JSON is not a general-purpose format, it was designed to be locked on javascript parsers.

If we want a popular markup language at some expense to save people from learning new language, it should be XML - it's more popular, than anything else.