Use of @optional attribute while serializing

[tchaloupka]

Lets have this code:

import std.stdio;
import std.typecons;
import vibe.data.json;

struct Bar { }

struct Foo
{
        long id;
        @optional Bar[] bars;
        @optional string name;
        @optional Nullable!long nullId;
}

void main()
{
        auto foo = Foo(1);
        writeln(foo);
        writeln(foo.serializeToJson());
        writeln(foo.serializeToJsonString());
}

It outputs:

Foo(1, [], "", Nullable.null)
{"nullId":null,"name":"","id":1,"bars":[]}
{"id":1,"bars":[],"name":"","nullId":null}

It would be nice if the serializer wont serialize fields that has initial value and are marked as @optional.

So we can have just this at the output:

{"id":1}

It could save a lot of data needed to be written to the output stream of REST API for example.

[deviator]

I think optional in and optional out must be separate. For example:

struct Foo
{
    @optional!In string bar;
    @optional!Out string baz;
}

{"baz":"ok"} valid json for this struct, but output json can be {"bar":"some"}, and not valid for input.
It can be useful in some cases.

[zunkree]

I believe non parameterized form will be little bit better:

struct Foo
{
    @optionalIn string bar;
    @optionalOut string baz;
}

because this @optional already parameterized with SerializationPolicy. Also, it is not so difficult to add such behavior I hope, but I need to figure out first how to skip fields during serialization.

[etcimon]

Add here: https://github.com/rejectedsoftware/vibe.d/blob/71123ecb3d21a8eb2860fad364aedc11927f1483/source/vibe/data/serialization.d#L479

    static if (hasAttributeL!(OptionalAttribute, TA))
        if (vt == typeof(vt).init) continue;

[crimaniak]

Instead of (or additional to) annotation it's possible to make special rendering case for Nullable because it's close related.

[tchaloupka]

Made a PR for this. Not sure what to do with Nullable as mentioned by @crimaniak.
Handle it as a both way optional by default?

[zunkree]

Any news?

[s-ludwig]

There is #1650, which has a working implementation, but the API should still be improved (see my last comments). I'm not sure about the best naming scheme, though, which is why I didn't offer a suggestion yet, so any ideas would be welcome.