Serialization library candidate review request

[GrimMaple]

On Monday, 28 August 2023 at 18:06:13 UTC, bauss wrote:
> On Monday, 28 August 2023 at 07:59:17 UTC, GrimMaple wrote:
>> On Monday, 28 August 2023 at 01:01:57 UTC, monkyyy wrote:
>>> I dont understand why your adding a uda rather then assuming 
>>> all values are serializable.
>>
>> Because on practice, you might want to leave some of the stuff 
>> unserialized. It's generally better (IMO) to specifically mark 
>> serializable fields. It also allows serializaing / 
>> deserializing properties and getters / setters.
>>
>
> I disagree. It's better to make fields serializable by default 
> and have an attribute to ignore serialization.

I disagree with your disagreement, because then you can serialize 
__everything__ and get garbage:
```d
auto f = File("myfile.txt", "rt");
serializeJSON(f); // ???
```

The attitutde of "everything is serializable" leads to tons of 
rules about __how__ everything is serialized, where a UDA creates 
a very simple ruleset. It's not that I don't understand the 
convenience of being able to serialize something without having 
to add `@serializable` to everything. It's inconveniences that 
this logic brings.

Consider phobos, for example. Someone will have to go around 
placing `@dontSerialize` to things so they produce any reasonable 
result (I might actually add a compile-time warning/error if type 
being serialized doesn't have things to serialize), otherwise 
you're gonna get garbage in your serialization out of the box.

Wrost-case scenario, it could be made that applying 
`@serializable` to the struct/class __itself__ would make 
everything inside it `@serializable`. Eg:

```d
@serializable struct Test
{
     int a;
}

assert(serializeToJSONString(Test()) == `{"a":0}`);
```