Update json.nim

[monocoder]

Add tuple and tuple array serialization.

var js = %(id: 1, name:"a")

var js2 = %[(id:1, name:"a"),(id:2, name:"b")]

var js3= %[(1,"a"),(2,"b")] #Unnamed tuple, name is automatically replaced by fields0, fields2

[dom96]

Hrm, I have a feeling there is a reason these don't exist.

[4ldas]

I don't really see a point in this

[Araq]

JSON doesn't have tuples, it's not all that clear how to map it to JSON. Also, it breaks somebody's code.

[timotheecour]

jsonutils.toJson is good enough:

nim --eval:'import std/[json,jsonutils]; echo (1,"f").toJson; echo (a:1, b:"f").toJson'
[1,"f"]
{"a":1,"b":"f"}

[ajusa]

This may not be the correct place to bring it up, but the documentation for one of the % procs says
## Construct JsonNode from tuples and objects.

Nim/lib/pure/json.nim

Lines 370 to 371 in 939702a

	proc `%`*[T: object](o: T): JsonNode =
	## Construct JsonNode from tuples and objects.

Based on that, I was led to believe that JSON serialization would work for tuples the way this PR handled them, but since that proc only accepts objects that isn't the case. @timotheecour has a good way to serialize a tuple to JSON, but I wonder if either the documentation should be updated to only say Construct JsonNode from objects. or if Nim should allow serializing tuples as a part of the json module directly.
Please correct me if I am wrong about what I'm assuming the documentation means here, I just put down what I interpreted it as after initially reading it.

EDIT: Also in 863848a it appears that the json module did have tuple serialization, and it was removed by f8e720f. That helps explain the documentation though.

[timotheecour]

I had added tuple support in #10010 but it was later removed in f8e720f with a commit that just said "fixes json.nim regression" without explaining what regression; @Araq what was the regression this was referring to?

[Araq]

I don't know anymore, but some package relied on not compiles(%{"error": "No messages"}) in some "meta/generic programming" context, of course.

[ajusa]

FWIW there are a few issues/pull requests that mention this specific issue.
#12290
#14638
From my understanding, marshalling JSON into a tuple works just fine, but unmarshalling a tuple to JSON isn't supported.
It's a bit inconsistent/confusing to me. Ideally named tuples could be serialized using the % operator. Not sure how you would want to handle unnamed ones, either compile time error or do the field0, field1 solution that a few PRs have proposed in the past (and this one).

[timotheecour]

Not sure how you would want to handle unnamed ones, either compile time error or do the field0, field1 solution that a few PRs have proposed in the past (and this one).

named tuples should serialize to a JObject
unnamed tuples should serialize to a JArray, as was done in #10010 and as is also done in jsonutils. Having it done differently would create inconsistency.

I don't know anymore, but some package relied on not compiles(%{"error": "No messages"}) in some "meta/generic programming" context, of course.

that's either too vague or doesn't seem like an actual regression. If some package adds in their tests

import sequtils, strutils, ...
doAssert not compiles(foo)

it shouldn't be sufficient grounds to prevent adding a symbol foo; it seems like something that package could easily accomodate with when compiles or when nimHasX or when (NimMajor, NimMinor, NimPatch) >= ....

I'd vote for reverting f8e720f unless there's some concrete arguments why this is bad.

[monocoder]

It is suggested that "json" and "jsonutils" should be merged to achieve a consistent user experience.

[Araq]

But what about users like me who don't want "jsonutils"?

[timotheecour]

modules are cheap, dependencies are not and cause issues with cyclic imports.

the original design of jsonutils was specifically intended to avoid having to import "the world" (ie all collections), but this regressed in #15133 which I tried to oppose in #15133 (comment)

The version I approved was before the commit Move JSON hooks to jsonutils.nim which IMO goes in the wrong direction; compared to right before that commit, jsonutils now adds a (recursive) dependency on at least 7 modules: os, osseps, pathnorm, posix, sets, strtabs, times, which have nothing to do with serialization.
In particular, os, posix and times are not lightweight dependencies.
This negates the whole point of the json hooks I had introduced in jsonutils (#14563), and prevents using jsonFrom, jsonTo in those modules due to cyclic dependency issues. Having toJsonHook/fromHsonHook in collections is arguably better, it just adds 2 symbols to collections but doesn't cause extra dependencies or prevent use of jsonutils in those modules.
See also #15133 (comment) above and #14549 (comment), it looks like we're going in circles...

The design before that PR allowed users to use jsonutils as a lightweight dependency, so maybe we should go back to that design.

[Araq]

We have an RFC for this we should follow, it relies on my unfinished concept work, but maybe my branch is good enough for it already.

[disruptek]

modules are cheap, dependencies are not and cause issues with cyclic imports.

Modules are cheap when they are not in the standard library. Just think about how easy it would be to change this behavior outside of stdlib.

How many modules have you published outside the stdlib, @timotheecour ?