Another serialization topic, reduced scope

[Steven Schveighoffer]

On 12/8/19 4:19 PM, Tobias Pankrath wrote:
> On Saturday, 7 December 2019 at 18:53:51 UTC, Jesse Phillips wrote:
>> @optional
> 
> If we look at e.g. json-schema.org or openapis.org they seem to have 
> optional by default. So we should at least consider this as well, e.g.
> 
> 1. have optional by default and introduce @required
> 2. make it configurable on the containing struct / class
> 
> enum IfMissing {
>      setDefault,
>      keep
> }
> 
> @missing(IfMissing.SetDefault)
> struct S
> {
>      // all fields by default optional due to @missing
>      @required
>      int x;
>      int a = 4; // set to 0 if not provided during deserialization
> }
> 
> 3. something else ..

First, I think the initiative is a good one. But in certain ways it is 
not enough.

I will tell you from first hand experience. I have types in my 
proprietary back end which are serialized in 2 ways -- one to the 
database, and one to a REST route as JSON. Specifically for one method 
of serialization, some things are ignored. For the other method of 
serialization, other things are ignored. For example, in the database, I 
may care very much that the id is serialized. But over Json, not at all.

So, the conclusion I came to (and actually, I use), is that I need to 
tag my members with BOTH, and have some way to distinguish them. That 
is, vibe.data.serialization.optional is a DIFFERENT attribute than 
db.DB.optional. And in my case, I use a DB struct, so all my attributes 
look like @(DB.optional) or @(DB.name!"class")

Decisions like whether the default is required or optional is very 
implementation dependent. Even the same mechanisms that are used in one 
project (i.e. Json serialization) may require a different default mode 
in another project.

And types may be defined that are used in both.

So how do we sort this out with a "universal" UDA system? I don't really 
know the answer. So far in my travels, I haven't needed to serialize 
types other than my own with serialization markers on it. So I control 
everything.

But that isn't always going to be the case. Perhaps in some cases, we 
need something other than UDA-based markers. Even setting the default 
may not be enough, maybe you need to generate a "dummy" struct which has 
the right UDAs on it. I go over something similar in this d meetup talk 
I did a while back: https://www.youtube.com/watch?v=ZxzczSDaobw

Part of me really likes the idea of a universal UDA system for 
serialization, to make things more general. But the other part of me 
feels like it's not a problem that can be solved universally -- it needs 
a local aspect. Is there a way to make it work both ways?

-Steve