Unable to provide #[serde( with = )] instructions

[fnordpig]

When trying to deserialize/serialize something with a custom handler for a field in a struct that needs to be handled by serde (specifically in my case chrono::DateTime<Utc> encoded with ts_milliseconds), it doesn't work. I had to wrap my DateTime<> members in a wrapper struct that I wrote. Not doing this causes huge performance problems as the default encoding / decoding is string based.

I can provide a working example if desired, but here's a snippet from my code reflecting my workaround:

#[derive(PartialEq, Debug, Serialize, Deserialize, Clone)]
pub struct DateTimeWrapper {
    #[serde(with = "ts_milliseconds")]
    pub time: DateTime<Utc>,
}


#[derive(Debug, Clone, PartialEq,  bincode::Decode, bincode::Encode)]
pub struct Quote {
    #[bincode(with_serde)]
    pub time: DateTimeWrapper,
    pub price: f64,
    pub size: f64
}

I would much rather it be:

#[derive(Debug, Clone, PartialEq,  bincode::Decode, bincode::Encode)]
pub struct Quote {
    #[bincode(with_serde)]
    #[serde(with = "ts_milliseconds")]
    pub time: DateTime<Utc>,
    pub price: f64,
    pub size: f64
}

Thank you for the excellent project by the way, I love the 2.0 can't wait to see it release.

[koshak01]

Why not provide native support for common types like ndarray, Datetime, and NativeDate?

---

After upgrading to Bincode v2, all my code broke, and I've been spending days rewriting it to fit the new approach.

I see that Decode/Encode were introduced to move away from serde, but why is there still no native support for commonly used types like ndarray, Datetime, and NativeDate? Instead, we have to manually annotate everything with #[bincode(with_serde)], which is quite inconvenient.

Wouldn't it make sense to provide built-in support for these types?

[VictorKoenders]

Note that you can still use #[derive(serde::Serialize, serde::Deserialize)] and use the bincode::serde:: functions. You don't have to switch derive attributes

[koshak01]

Thanks for the clarification! I understand that we can still rely on #[derive(serde::Serialize, serde::Deserialize)] and the bincode::serde:: functions, which is helpful. However, it does leave me wondering—if we’re still leaning on Serde for these common cases, what’s the real benefit of moving to Bincode v2? I was hoping the new version might streamline things further.

I’d really love to take advantage of native decoding support for types like ndarray, Datetime, and NativeDate without needing to sprinkle #[bincode(with_serde)] across every class—it’d make the transition feel a bit smoother. Anyway, just my two cents, and I appreciate your input!

[VictorKoenders]

There is a list of known issues and a paragraph on why we decided to make serde an optional feature here: https://docs.rs/bincode/latest/bincode/serde/index.html#known-issues

If bincode v1 works well for you, there is no problem with staying on bincode v1.

Going to close this in favor of letting people use #[derive(serde::Serialize, serde::Deserialize)] instead of having serde annotations on a bincode derived struct.