互操作性

从数据结构到非数据结构存在一个连续体，其中有一部分是灰色区域。LinkedHashMap 和 IpAddr 是数据结构。有人希望从 JSON 文件中读取 LinkedHashMap 或 IpAddr，或者通过 IPC 将其发送到另一个进程，这是完全合理的。而 LittleEndian 不是数据结构。它是 byteorder crate 使用的一种标记，用于在编译时针对特定字节顺序进行优化，实际上 LittleEndian 的实例在运行时永远不会存在。这些是明确的例子；#rust 或 #serde IRC 频道可以帮助评估更多模棱两可的情况。

如果一个 crate 没有因为其他原因依赖于 Serde，它可以选择通过 Cargo 配置选项来控制 Serde 的实现。这样，下游库只需要在需要这些实现时支付编译 Serde 的代价。

为了与其他基于 Serde 的库保持一致，Cargo 配置的名称应为 "serde"。不要使用 serde_impls 或 serde_serialization 等不同的名称。

在不使用派生的情况下，规范的实现看起来像这样：

[dependencies]
serde = { version = "1.0", optional = true }

#![allow(unused)]
fn main() {
pub struct T { /* ... */ }

#[cfg(feature = "serde")]
impl Serialize for T { /* ... */ }

#[cfg(feature = "serde")]
impl<'de> Deserialize<'de> for T { /* ... */ }
}

使用派生时：

[dependencies]
serde = { version = "1.0", optional = true, features = ["derive"] }

#![allow(unused)]
fn main() {
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct T { /* ... */ }
}

类型在可能的情况下实现 `Send` 和 `Sync`（C-SEND-SYNC）

当编译器确定合适时，Send 和 Sync 会自动实现。

在操作原始指针的类型中，要谨慎确保你的类型的 Send 和 Sync 状态准确反映其线程安全特性。类似于以下的测试可以帮助捕捉类型是否实现 Send 或 Sync 的非预期回归。

#![allow(unused)]
fn main() {
#[test]
fn test_send() {
    fn assert_send<T: Send>() {}
    assert_send::<MyStrangeType>();
}

#[test]
fn test_sync() {
    fn assert_sync<T: Sync>() {}
    assert_sync::<MyStrangeType>();
}
}

错误类型应具有意义且表现良好（C-GOOD-ERR）

错误类型是任何 Result<T, E> 中的 E 类型，它由你的 crate 的任何公共函数返回。错误类型应始终实现 std::error::Error trait，这是错误处理库如 error-chain 抽象不同错误类型的机制，并且允许错误作为另一个错误的 source()。

此外，错误类型应实现 Send 和 Sync trait

Rust API Guidelines