4

If I have something like

use serde_json;
use iso8601::DateTime;

#[derive(Deserialize, Debug)]
pub struct Thing {
    pub attr: i32,
    pub foo: i32,
    pub ts: DateTime
}

The compiler is also going to insist that I ensure DateTime satisfies the trait bound Deserialize:

error: the trait bound `iso8601::DateTime: serde::Deserialize` is not satisfied [E0277]
src/lib.rs:208   #[derive(Deserialize, Debug)

You can't place the derive annotation above the included struct, or the compiler will complain. In fact, the plot thickens, as DateTime itself has structs that would need the same annotation:

pub struct DateTime {
    pub date: Date,
    pub time: Time,
}

Is there a way to swing this, or do I have to implement these traits manually for external structs?

Edit: Let me be clear, I was asking about the #[derive] macro. I read the linked and related questions, and I understand that I can provide my own implementation of different traits, as well as use newtypes etc. That is not what I am asking about.

Cargo.toml

serde = "0.8"
serde_json = "0.8"
serde_macros = "0.8"
iso8601 = "0.1.1"
bright-star
  • 6,016
  • 6
  • 42
  • 81
  • 3
    A simple "no" answer with relevant information would be more useful (in the SO sense) than voting to close as duplicate. Edited to explain further. – bright-star Aug 05 '16 at 18:46
  • The relevant information *is* the linked duplicate and [the question it is a duplicate of](http://stackoverflow.com/q/25413201/155423). *How* you attempt to implement the trait is immaterial, it still cannot be done. – Shepmaster Aug 06 '16 at 14:53
  • 2
    I don't mean any offense by it, but I disagree that the 'how' is immaterial--it's not immaterial to me. I would like to know whether or not the code intended to be generated by a custom `derive` macro can be applied to an imported struct, especially one that wraps other imported structs. In this same vein, the question you link to mentions the [newtype_derive](https://crates.io/crates/newtype_derive) crate, which might provide a macro for this job. So which is it? Not possible, or not expressible this way? Because the linked question puts both of those forks in question without answering them. – bright-star Aug 07 '16 at 05:10
  • In my opinion, this is one of the most important reasons to implement a fix for this issue. Aside from suffering from strange "wrapping" issues with the new type, implementing this manually can be a large amount of code duplication, depending on the trait being implemented and the level of nesting. – mboratko Jun 20 '18 at 02:56

0 Answers0