3 ms·
In case the author of the article is reading... > This is because Rust’s attribute grammar can’t support a callable here. The grammar of attributes supports i
by shepmaster 2y ago
In case the author of the article is reading...
> This is because Rust’s attribute grammar can’t support a callable here.
The grammar of attributes supports it fine, it's just that Serde chooses to not use it. I'm not sure if it's because Serde started before it was allowed or if it's a stylistic preference or what.
For example, my crate SNAFU allows you[1] to use attributes containing types (`Error`) and expressions (`Box::new`):
#[derive(Debug, Snafu)]
#[snafu(source(from(Error, Box::new)))]
struct ApiError(Box<Error>);
[1]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#transforming-the-source https://docs.rs/snafu/latest/snafu/derive.Snafu.html#transfo...
- steveklabnik 2y agoThis is also my error, and the author has been informed. He just hasn't updated the post yet, but will. I forgot that this got stabilized. It's easy to lose track of everything sometimes! EDIT: oops forgot to reply to this: > I'm not sure if it's because Serde started before it was allowed or if it's a stylistic preference or what. This was stabilized post 1.0, and serde is (as you know) older than Rust 1.0. That's why I thought that it wasn't possible. https://doc.rust-lang.org/1.0.0/reference.html#attributes https://doc.rust-lang.org/1.0.0/reference.html#attributes says > An identifier followed by the equals sign '=' and a literal, providing a key/value pair Of course, we didn't even have stable proc macros at that point. I tried to dig into the exact history here for a bit, but didn't manage to find the exact point at which this came to be, it was taking too long.
- OptionOfT 2y agoI'd love to read more on how you implemented this. I hope I don't sound lazy, but can you point me a starting location to read up on it? Maybe it's something I can backport to serde.
- shepmaster 2y agoCode-wise, it's not too painful [1], the problem is that you need to enable more features for syn. By default, syn doesn't compile in support for parsing arbitrary types / expressions, which does increase the time / space needed. Since syn is a pretty fundamental crate, I've a feeling that Serde probably doesn't want to turn on this feature for minimal gain, but that's pure speculation on my part. [1]: https://github.com/shepmaster/snafu/blob/1dbba9514e2abfdff015ef8ff895510429d0ebef/snafu-derive/src/parse.rs#L764-L784 https://github.com/shepmaster/snafu/blob/1dbba9514e2abfdff01... [2]: https://github.com/shepmaster/snafu/blob/1dbba9514e2abfdff015ef8ff895510429d0ebef/snafu-derive/Cargo.toml#L22 https://github.com/shepmaster/snafu/blob/1dbba9514e2abfdff01...