Serialization library candidate review request

[Mathias LANG]

On Sunday, 27 August 2023 at 19:39:05 UTC, GrimMaple wrote:
>
> I tried to make it as universal as I could, but any suggestions 
> are welcome for a discussion.

TL;DR:
- Build escape hatch first, then idioms;
- Composability is key;
- Use dedicated data structure for serialization, don't mix with 
business code;
- Sane defaults based on the language if possible, UDA for 
exceptions;

Long version:

1) From experience, the biggest challenge is the code you do not 
control.
You need an escape hatch when you can't edit the code but need 
something specific, e.g. you have a struct with a deeply nested 
component that you want serialized in a certain way.

2) That escape hatch should compose well with the regular case, 
so that you only have to specialize the tiny bit you need, and 
don't need to copy some of the logic of the tool.

3) Once you have this in place, you can start adding idioms / 
patterns you want to expose. Each pattern you expose will make 
assumptions that will reduce the formats you can support (e.g. 
what if the format can only have 2 levels of nesting?), so a lot 
of it will be judgement calls. You don't want to mix business 
code with serialization code, because things will get messy very 
quickly. In your example, the `@Serializable` attribute is the 
wrong approach - not serializing something in a struct you are 
giving to the serializer should be the exception rather than the 
rule.

4) Whenever possible, use the language rather than UDA. For a 
value that is optional, give it an initializer (because it 
doesn't make sense for something that is required to have a 
default value).

I wrote a deserialization library to read YAML configuration 
files and validate them based on those principles 
(https://github.com/dlang-community/configy). I'm not 100% happy 
with it, but starting from the escape hatch and building on top 
of that allowed me to always fulfill my needs.

Note that something making its way into Phobos, it would be the 
right time to add `core.attributes` as well. Things like 
`@Name("newname")` are no brainers. We might or might not want to 
decide on some convention, e.g. do we assume `public_` is 
serialized as `public` or do we always need an UDA ?