Usage of serde_as on field of enum's tuple variant

[spikespaz]

I have the following enumeration:

#[serde_as]
#[derive(Debug, Clone, PartialEq, Eq, Hash, Display, SerializeDisplay)]
pub enum ProjectIdentifier {
    Id(#[serde_as(as = "Base62Encoded<u64>")] u64),
    Slug(String),
}

When running a cargo check, I see:

error: cannot find attribute `serde` in this scope
  --> src/types/project.rs:11:1
   |
11 | #[serde_as]
   | ^^^^^^^^^^^
   |
   = note: `serde` is in scope, but it is a crate, not an attribute
   = note: this error originates in the attribute macro `serde_as` (in Nightly builds, run with -Z macro-backtrace for more info)

When I use the following, the compiler does not complain:

#[serde_as]
#[derive(Debug, Clone, PartialEq, Eq, Hash, Display, SerializeDisplay)]
pub enum ProjectIdentifier {
    #[serde_as(as = "Base62Encoded<u64>")]
    Id(u64),
    Slug(String),
}

But my question here is; what if I wanted different invocations of the proc-macro on multiple tuple-fields? For example:

#[derive(Debug, Clone, Display, SerializeDisplay)]
pub enum IDontKnowThing {
    ImaVariant(
        #[serde_as(as = "Vec<Base62Encoded<u64>>")] Vec<u64>,
        #[serde_as(as = "Base62Encoded<u128>")] u128
    ),
}

Is such a thing possible? How does having the invocation of serde_as attribute macro affect a tuple variant with multiple fields? And will the above example that compiles even work as I expect?

If you're curious, this is base62.rs:

use std::str::FromStr;

use serde::{Deserialize, Serialize, Serializer};
use serde_with::{DeserializeAs, DeserializeFromStr, SerializeAs, SerializeDisplay};

#[derive(PartialEq, SerializeDisplay, DeserializeFromStr)]
pub struct Base62Encoded<T>(pub T);

impl<T> std::fmt::Display for Base62Encoded<T>
where
    T: Clone + Into<u128>,
{
    fn fmt(&self, formatter: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        formatter.write_str(&base62::encode(self.0.clone()))
    }
}

impl<T> FromStr for Base62Encoded<T>
where
    u128: TryInto<T>,
{
    type Err = base62::DecodeError;

    fn from_str(other: &str) -> Result<Self, Self::Err> {
        match base62::decode(other)?.try_into() {
            Ok(n) => Ok(Base62Encoded(n)),
            Err(_) => Err(Self::Err::ArithmeticOverflow),
        }
    }
}

impl<T> SerializeAs<T> for Base62Encoded<T>
where
    T: Clone + Into<u128>,
{
    fn serialize_as<S>(source: &T, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer,
    {
        Base62Encoded(source.clone()).serialize(serializer)
    }
}

impl<'de, T> DeserializeAs<'de, T> for Base62Encoded<T>
where
    u128: TryInto<T>,
{
    fn deserialize_as<D>(deserializer: D) -> Result<T, D::Error>
    where
        D: serde::Deserializer<'de>,
    {
        Base62Encoded::deserialize(deserializer).map(|n| n.0)
    }
}

[jonasbb]

Hi there, most features of this crate are there to make it easier to use the derive macros serde::Serialize and serde::Deserialize in situations, which don't quite follow the usual rules and need some adjusting. Everything related to serde_as is part of that.

The problem with your ProjectIdentifier is that you are not deriving serde::Serialize or serde::Deserialize. The serde_as annotation on the u64 field will be converted into a serde annotation, but this is not understood by any of the derive macros. Therefore, you see the error. It seems like you forgot to derive serde::Deserialize or accidentally used SerializeDisplay instead of serde::Serialize.
SerializeDisplay does not interact with serde or serde_as attributes.

When I use the following, the compiler does not complain:

#[serde_as]
#[derive(Debug, Clone, PartialEq, Eq, Hash, Display, SerializeDisplay)]
pub enum ProjectIdentifier {
    #[serde_as(as = "Base62Encoded<u64>")]
    Id(u64),
    Slug(String),
}

serde_as does not work on enum variants. It is only meant to be used on fields. The #[serde_as] above the derive is the macro which then processes all the other attributes on the various fields.
This example compiles because it is equivalent to not using serde_as at all.

In the case of your IDontKnowThing I don't see any reason why two attributes on different fields shouldn't work. You are missing a #[serde_as] above the derive, though. And the same misunderstanding of the first code snippet applies here too. If you only use SerializeDisplay you don't need or want serde_as. If you use serde_as it must be paired with either serde::Serialize or serde::Deserialize derives.

[spikespaz]

I have tried the following, but it has the same error as the original attempt without Deserialize. The #[serde_as] says it cannot find an attribute serde.

// TODO: Find a way to use `serde_as` without deriving `Deserialize`, because
// TODO: `Deserialize` on this type is undefined behavior.
#[serde_as]
#[derive(Debug, Display, Clone, PartialEq, Eq, Hash, SerializeDisplay)]
pub enum ProjectIdentifier {
    #[display(fmt = "{}", _0)]
    Id(#[serde_as(as = "Base62<u64>")] u64),
    #[display(fmt = "{}", _0)]
    Slug(String),
}

impl<'de> Deserialize<'de> for ProjectIdentifier {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>,
    {
        unimplemented!();
    }
}

[jonasbb]

There still seems to be a misunderstanding of the fundamental problem. Let me rephrase me initial answer, maybe that helps.

You cannot have serde_as and SerializeDisplay on the same struct. You need to pick one of these options:

•   #[serde_with::serde_as]
    #[derive(serde::Serialize)]

•  #[derive(serde_with::SerializeDisplay)]

I don't understand why you thought you need to use Deserialize here, or even implement it manually.

[spikespaz]

There still seems to be a misunderstanding of the fundamental problem. Let me rephrase me initial answer, maybe that helps.

Your rephrasing helps me understand what is going wrong here, that SerializeDisplay and #[serde_as] are conflicting. It does not necessarily explain the fundamental problem.

The misunderstanding arises from this:

The problem with your ProjectIdentifier is that you are not deriving serde::Serialize

I thought that SerializeDisplay derives Serialize but makes use of the Display trait?

It does. It requires that you impl Display for ProjectIdentifier and uses serializer.collect_str(self) to serialize the value. It does not care about individual fields. That means, the Display implementation needs to do all of the heavy lifting and convert everything into the correct shape. For serde, it will only see a single string.

I asked if SerializeDisplay derives Serialize, and your answer was yes. I understand how the implementation works, wherein Display does the work, and the derived Serialize collects the produced &String into the Serializer.

From my understanding, serde_as requires that Serialize and Deserialize (more about the latter later) are implemented for ProjectIdentifier. Since you confirmed that SerializeDisplay produces the Serialize implementation, I had assumed that it would be sufficient for the outer serde_as to make use of (and wrap or change) Serialize. The fundamental problem still remains unclear to me.

Why are serde_as and SerializeDisplay incompatible? Is it because SerializeDisplay implements SerializeAs as well as Serialize, and therefore serde_as would end up producing a conflicting implementation?

SerializeDisplay does not interact with serde or serde_as attributes.

This makes some sense, but I need some help understanding what you mean by "interact". I assumed that serde_as depends on Serialize and Deserialize, this is what I mistakenly understood to be the interaction. It would seem that serde attributes would conflict with the rigid form implemented by the SerializeDisplay derive, but no such issue should be between this and serde_as.

I suppose what I don't understand is the outer #[serde_as] and thought that the inner #[serde_as(as = "...")] would determine the behavior of the serialization of the inner type. For example, ProjectIdentifier's Serialize implementation would make use of the result of Base62<u64>::serialize_as for the field of the Id variant, not conflict with it. I was trying to nest the behavior, this made sense in my head.

[spikespaz]

I had tried to derive Deserialize because I assumed that it would be required.

[jonasbb]

Maybe it helps you to visualize better what is going on, if you take a look at the documentation of all the involved macros and look at expanded code after the macros run, e.g., with the playground or https://github.com/dtolnay/cargo-expand.

The problem with your ProjectIdentifier is that you are not deriving serde::Serialize

I thought that SerializeDisplay derives Serialize but makes use of the Display trait?

It does. It requires that you impl Display for ProjectIdentifier and uses serializer.collect_str(self) to serialize the value. It does not care about individual fields. That means, the Display implementation needs to do all of the heavy lifting and convert everything into the correct shape. For serde, it will only see a single string.

I asked if SerializeDisplay derives Serialize, and your answer was yes. I understand how the implementation works, wherein Display does the work, and the derived Serialize collects the produced &String into the Serializer.

Yes, the SerializeDisplay (derive macro) derives an implementation of the Serialize (trait). That is correct. In my original message I was referring to the serde::Serialize (derive macro).

Why are serde_as and SerializeDisplay incompatible? Is it because SerializeDisplay implements SerializeAs as well as Serialize, and therefore serde_as would end up producing a conflicting implementation?

In the documentation of the serde_as macro you can see what it does. The important part here is that a field with a #[serde_as(as = "...")] attribute will receive a new attribute roughly like #[serde(with = "::serde_with::As::<...>")]. The documentation of the SerializeDisplay derive macro shows which attributes it accepts/consumes. You'll see, that the serde attribute is not on the list. This means, with this combination (serde_as attribute macro plus SerializeDisplay derive macro), nothing understands the serde attribute.

The two (main) things which understand the serde attribute are the two derive macros from the serde crate, i.e., serde::Deserialize and serde::Serialize.

SerializeDisplay does not interact with serde or serde_as attributes.

This makes some sense, but I need some help understanding what you mean by "interact". I assumed that serde_as depends on Serialize and Deserialize, this is what I mistakenly understood to be the interaction. It would seem that serde attributes would conflict with the rigid form implemented by the SerializeDisplay derive, but no such issue should be between this and serde_as.

If you look at the documentation of SerializeDisplay (link above) it tells you, which attributes it can understand. It can only understand a serde_with attribute. Nothing else. This means, it doesn't know what a serde or serde_as attribute mean, it will not process them, read them, or tell rustc that this is a helper attribute. This means that rustc knows that nothing understand the serde attribute and will raise an error for that.

I am unsure what you mean here with "depends on". If you mean the Serialize and Deserialize traits, then no. serde_as is not aware of the traits nor does the expanded code use these traits. If you mean the serde::Serialize and serde::Deserialize derive macros, then somewhat, but not strictly. The generated code is designed to be consumed by the two serde::Serialize and serde::Deserialize derive macros. Other "compatible" derive macros would also be acceptable. The SerializeDisplay derive macro is not such a macro.