Why does serde_as remove its own attribute/annotation?

[Lehona]

When #[serde_as] is applied to a struct, it replaces all #[serde_as(as = "foo")] attributes on the struct's fields with regular #[serde] attributes. I realize that this is required to work, but is there any reason not to leave the #[serde_as(as = "foo")] attribute in place? I'm using a proc macro to parse out the #[serde_as(as = "foo")] information and if the proc macro is applied after #[serde_as] on the struct this information is just gone (or at least hard to parse).

For now I can easily fix it by making sure my proc macro is applied first, but I'd much prefer if my users didn't have to care about that :)

[jonasbb]

Short answer: If the attributes are kept rustc will not compile the programs and will error with expected an inert attribute, found an attribute macro.

Longer answer:
Currently, the serde_as system is implemented as a proc-macro attribute, which do not have the luxury of declaring additional attribute names which it will consume. Derive macros can do that, and they do not have to remove the field attributes. In fact, they cannot remove them.
Field attributes are still required though, so either they re-use the serde_as attribute name or an unknown attribute name. Unknown attributes would also cause compiler errors. Since serde_as is re-used it causes the error message above, since you are not allowed to apply proc-macro attributes on fields.
So either way the field attributes need to be removed.

So right now I see two possible solutions:

1. proc-macro attributes could also declare additional attribute names which, if left in the code, would not cause any compiler errors. I don't know if something like this is planned or even possible.
2. serde_as and serde_derive could be merged/integrated in some way. Personally, I would find it very nice if serde_as wouldn't use the attribute macro anymore, but instead simply use the normal derive macros. However, this would require that either serde consumes part of this crate (the SerializeAs/DeserializeAs traits and helper types like As would need to move) or to fork serde_derive and extend it myself.

---

In your case you could see if you want to parse the #[serde] attributes or maybe your proc-macro could simply place the #[serde_as] attribute?

1. The #[serde_as] attribute performs this conversion and nothing more right now:
   #[serde_as(as = "$FOO")] → #[serde(with = "As::<$FOO>")] so it should not be that much worse to parse. It actually expands more to something like #[serde(with = "$crate::As::<$FOO>")] where $crate defaults to ::serde_with and can be overwritten.
2. You didn't specify what the relation between your proc-macro and serde_as is, like if serde_as is always or only sometimes present. But you could re-export serde_as from your crate, and make your proc-macro always (or only if necessary) apply the serde_as attribute. There is no ordering problem if only one attribute exists.

[Lehona]

I see, thanks for the explanation. For now I will probably just leave it as-is, with a note that parsing the serde-attribute may be possible in the future to allow arbitrary ordering. Applying serde_as myself is an interesting thought, though.

[dtolnay]

the serde_as system is implemented as a proc-macro attribute, which do not have the luxury of declaring additional attribute names which it will consume

They do, but there is an extra step where the attribute macro needs to attach a derive that identifies which inert attributes the attribute macro is claiming.

#[proc_macro_derive(serde_as_attributes, attributes(serde_as))]
pub fn attributes(_: TokenStream) -> TokenStream {
    TokenStream::new()
}
// then put derive(serde_as_attributes) on input

[jonasbb]

Thanks @dtolnay, that is a nice idea to work around this limitation. I will keep that in mind if this question appears again.

[dtolnay]

Why not implement it that way now? That would let @Lehona's crate eliminate the limitation of requiring a particular ordering of the attributes written by the user.

[jonasbb]

Why not implement it that way now?

Fair enough. I don't think I have a good answer, except I wasn't sure how the cost in change and maybe downsides of adding a dummy derive macro compares to having this ordering limitation.
Given that you proposed this and didn't mention anything more I assume it is basically without downsides except for calling this empty derive-macro.

So maybe that change should also apply to skip_serializing_none since that also has a field attribute and to keep the logic between the different proc-macro attributes similar.

@Lehona I will try to implement the suggestion of @dtolnay, maybe already over the weekend.

[jonasbb]

I updated the code in #262. The code change was easy enough, since the macro already requires knowledge where serde_with is imported. skip_serializing_none works right now without that information, so it doesn't have a good way to refer to other macros in the same code.