On Monday, 9 December 2019 at 03:21:47 UTC, Jesse Phillips wrote:
> On Sunday, 8 December 2019 at 22:00:53 UTC, Steven Schveighoffer wrote:
>
>> 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")
>
> I figured this would be likely. I took a look and it would be possible to specify a template argument to the attribute, the libraries could supply a type, we could supply some generic ones (DB, Web, Disk, Unspecified)
>
> I'll watch the video.

I took some more time to expand on the idea. While I didn't get my custom getUDA to work perfectly, it looks promising.

https://github.com/JesseKPhillips/DIPs/blob/serialize/attribute/DIPs/1NNN-jkp/serialattr.d

Basically the implementation will provide an attribute which takes an attribute to match on.

@SerializerDB!DB
struct Example {
    @Ignore!DB

The standard library will need to help search these attributes.

Ethan,

https://youtu.be/rSY78Hu8DqI

In your talk you mention needing

OnPreSerialize
OnPostSerialize
OnPreDeserialize
OnPostDeserialize

Could you explain the seed semantics for these?

Right now OnPostDeserialize on the class itself (not field) can be used for filling internal fields.