json and json2 issues

[ghost]

Describe the bug

If any of these issues can already be closed, please do so if you have the authority.

If we are integrating into json2, the problems we have with json should be resolved in json2.

json
encode

• json marshaling of shared variable causes compiler error #11551
• Can't use json.encode_pretty with struct literal #12118
• [omitempty] for strings causes compilation error #12570
• Fixed-length arrays cannot be json-encoded #14698
• Passing a struct with an enum array with json.encode produces a compile bug #15093
• json.encode fails under some circumstances #15840
• build error json.encode() optional field. #16462

decode

• Decoding malformed JSON doesn't fail #2408
• [Enhancement] json module can not decode on some case on array. #6344
• json parser not reporting syntax errors #6932
• Native JSON support #7032
• Compiler bug decoding json to primitive type #10157
• json.decode() into primitive types #11492
• orm: failed to detect mismatched column type #12425
• json: struct field on heap causes compile time error #12808
• Compiler bug when json arg contains struct with a ref struct field #13212
• json.decode on a sum type with a struct variant, results in incorrect data when the input json does not have a _type field #14058
• Map keywords are not prefixed with @ when printing struct with content #14709
• json: wrong parse in bool an and int #14906
• Unable to decode struct with Sumtype. "unknown sum type value" #15081
• json.decode does not parse time into Struct #15610
• multiple field attributes does not work #16434

x.json2

• infix expr: cannot use map_string_string (right expression) as x.json2.decode #6722
• bug: casting .int() and .f64() in x.json2 #14509
• ignored if and match #15921
• json and json2 (encode): multiple errors #15923
• x.json2 encoding optional field results in C error #16472
• json2 does not encode u32 #16484

[ghost]

In my personal opinion, as a transition from json to json2, Why not use json.decode() in x.josn2.decode() so that json2 can also decode easily?
cjson should only be used inside json2.

Then at least all encoding issues would be consolidated into json2.
This allows json users to essentially migrate to json2 with minimal changes.

Then we can free ourselves from the hassle of from_json() in json2.
Then we can gradually develop a json2.decode() that does not use cjson.

[spytheman]

cjson should only be used inside json2.

The whole point of json2, is that it is pure V code, and does not depend on a C library.

[ghost]

I know it? As a transitional measure, but I guess I didn't explain it well enough?
As you can see from the list above, many users seem to be choosing json instead of json2.
This kind of situation will not change unless we change first.
And it would be useless to maintain both json and json2, right? Because the json module is scheduled for obsolescence.
As long as users continue to use the json module, migration is a long way off, right? Because people don't pay attention to json2.
So cjson is used internally, only in decoding. Then we can gradually replace it with V code. Are there any technical impossibilities in this? I don't know.

Anyway, I want to remove from_json() from json2.decode().
This is my reason for not using json2.

import x.json2

struct Foo{
	name string
}

fn main(){
	f := json2.decode<Foo>('{"name":"abc"}') or {return}
	dump(f)
}

/home/tsukasa/lang/v/vlib/x/json2/json2.v:24:6: error: unknown method or field: `Foo.from_json`
   22 |     res := raw_decode(src)!
   23 |     mut typ := T{}
   24 |     typ.from_json(res)
      |         ~~~~~~~~~~~~~~
   25 |     return typ
   26 | }

Then the user uses json2 for encoding and json for decoding. Do you think they would do that? I don't think so. They would use json for both.
But as a developer, you want people to use pure V json2, right?
That's why I proposed a compromise above. Even for developers, you don't want to fix a deprecated json module, do you?

Of course, we could wait until json2.decode() no longer requires from_json(). However, unless people demand it loudly, it will not be implemented promptly. Because we already have json.decode().

Besides do you want to leave the above json related many bugs until from_json() is removed from json2.decode()?
I would choose to integrate it into json2 and improve json2 rather than leave those bugs alone.
Because encode is already available in json2, and as you say, it's pure V, so bug fixes and improvements should be easy.
This would force people to use json2. (A few minor generics-related modifications are needed, though. )
At the same time, all json-related issues above will change or disappear to json2-related issues.
Thus, all ordinary users will be able to use json2 conveniently. The general user is not interested in whether it is pure V or not until it is hidden.

After this, developers who want pure V should make an effort to remove cjson from json2.

However, when sorted out, decoding is by far the more problematic.
But on the other hand, it could be considered more important to remove from_json().

[Avey777]

JSON2 should be able to replace JSON, right

[JalonSolov]

Eventually. Still needs some work.