V: JSON serielization - way to represent null values

[danieldaeschle]

in V, there is no null/nil/none/whatever.
But in JSON null is valid value. And there is also a difference between null and "" or 0.

as example:

{
    "email":  null,
    "name": "foo"
}

user has no email address

{
    "email": ""
    "name": "foo"
}

users email address is invalid...

Maybe it's a bad example, but there are a lot of usecases where a representation of null is needed.. natively.

[JalonSolov]

A lot of other languages have null as a valid value. Interestingly enough, c doesn't. It's a common #define, but it's not a part of the language.

However, almost every language which has it uses null as a convenience to mean "unset" or "undefined". There are probably better ways to deal with this.

For example, Perl doesn't have null either, but it does have an explicit "undef" keyword ("foo = undef" is similar to "foo = null" in other languages) with matching "if defined" check (which is different from "if foo == null"), as well as explicit error messages when you try to do something with it before you've set it ( "reference to undefined value") instead of blowing up like c will with an undefined value (like a pointer that hasn't been initialized).

Interoperability between languages is not always easy. :-\

[RiordanIX]

Maybe in the JSON serialization module there could be a flag for each key on whether it's null or not?

[danieldaeschle]

Optional does this. But it's overhead.

[dumblob]

Rough idea:

a) typedef json_null_type as an enum consisting of one member json_null
b) typedef a variant type json_node as json_null_type|string|f64
c) use json_node to manipulate JSON strings

Btw. it might make sense to restructure the current JSON API to allow for fully lazy parsing.

[JalonSolov]

Only as an option. Sometime you want strict parsing.

[dumblob]

Only as an option.

Are you referring to the variant type idea or to the lazy parsing of JSON?

Sometime you want strict parsing.

What is "strict parsing" (couldn't find anything on the web)? Do you mean "fully up front parsing"?

[JalonSolov]

Referring to lazy parsing.

Strict would be strictly according to the JSON spec, rather than allowing common "lazy" variations (such as single quotes instead of double, or not putting quotes around keys, or... whatever). You might be referring to what I've always called stream parsing, where it only parses part of it at a time, as you ask for it.

It would also be nice to have 2 other optional features...

1. Some systems, such as Gerrit, send a "prefix" on the data to help prevent Cross Site Script Inclusion.

The Gerrit system always sends this line

)]}'

before the actual JSON data. Providing a way to have the library skip that data, instead of me having to write code to do it every time would be handy. Gerrit isn't the only system that does this, and they each have a different prefix, so it would have to be a string that I send to the decoder.

1. Support for JSON5 format.

[dumblob]

Thanks for clarification. Sure, I meant stream parsing (I hate non-conforming behavior, so I'd definitely like to parse JSON strictly according to spec by default).

As for prefixing JSON data, wouldn't it be enough to just slice the data from left (thus avoiding extension of API)?

Regarding JSON5, I'm not convinced we want that built-in as it's not wide spread IMHO. On the other hand if supporting it wouldn't require much more code than the standard JSON, then why not :wink:.

[JalonSolov]

The advantage of supporting JSON5 is that we could stick with JSON but get "missing features" like comments, floating point numbers, etc., instead of all the less than ideal formats people keep trying to switch to. Like YAML and TOML (which is just Windows INI files, but with nesting). :-\

JSON5 doesn't have wide adoption, yet, but having support for it built-in might help change that.

[danieldaeschle]

yaml is nice, but we are talking about traditional json here.

[JalonSolov]

YAML, in my opinion, has 2 serious flaws.

1. whitespace indent to show blocks.

That is entirely _too_ easy to mess up, and the enforced spaces vs tabs just wastes space in the file.

1. No 100% accurate way to tell what type a value is supposed to be without reading the code.

Take this line:

foo: 1

Is foo a number or a string?

In JSON, there's no question...

NUMBER: "foo": 1

STRING: "foo": "1"

Silly arguments about using less punctuation are just that. Silly.

But, as you say, this issue is about JSON, not anything else.

[sambeckingham]

Would it not be pragmatic to use the language norms, and say that if a JSON value is nullable then define it as an Option. For example

{
    "email":  null,
    "name": "foo"
}

Would be

struct User {
    email ?string
    name  string
}

Assuming name isn't nullable? Sorry if this seems wild, I've only discovered V as of yesterday evening but it seems Option is V's way of dealing with undefined values and thus would make sense to use here.