Rustのserdeで&'a [T]をフィールドに持つ構造体をデシリアライズする方法

Question

以下のようなソースコードを書いているのですが、struct Aでエラーが起きてしまいます。
エラー文から対処方法を解読できず、なにを実装すればいいのか悩んでいます。
多少強引な方法でも良いので、解決方法を教えていただきたいです。

#[derive(Serialize, Deserialize)]
pub enum MyEnum{
    A,
    B,
    C,
    D,
    E,
}

#[derive(Serialize, Deserialize)]
pub struct B{
    pub num: u32,
    pub level: i32,
    pub param: MyEnum,
}

#[derive(Serialize, Deserialize)]
struct A<'a> {
    data: &'a [B], // ここでエラー[E0227]
    index: usize,
}

[E0277] the trait bound `&'a [B]: Deserialize<'_>` is not satisfied. 
[Note] the trait `Deserialize<'_>` is not implemented for `&'a [B]`

serdeのバージョン:
serde = { version = "^1.0.126", features = ["derive"] }
serde_json = "^1.0.64"

Answer 1

方法1

最も正しいと思われる方法は、参照を使うのを諦める方法です。 &str や &[u8] などの特別な場合 (zero-copy deserialization) を除き、serdeは参照をデシリアライズできません。

#[derive(Serialize, Deserialize)]
struct A {
    data: Vec<B>,
    index: usize,
}

何らかの理由で data: &[B] としなければいけない場合、まずその理由を再検討してください。

• Vec のアロケーションコストが気になっていますか？配列のデシリアライズをしたいのであれば、これはほぼ間違いなく必要で妥当なコストです。Rustは不要なアロケーションコストを削ることはできますが、必要なアロケーションコストを削ることはできません。
• Vec のコピーコストが気になっていますか？もし配列が大きく、かつコピーが頻繁に発生しそうなら、 Rc<Vec<B>> または Arc<Vec<B>> として中身のコピーコストを抑えるのがいいでしょう。
• 後続のAPIが data: &[B] を要求していますか？ どうしてもそのAPIを変えられない場合、 data: &[B] を持つ struct A<'a> と data: Vec<B> を持つ struct AOwned を用意して、デシリアライズしてから AOwned → A の変換を行うという手があります。このような冗長なコードは、Rustでパフォーマンスを追求するとしばしば起きてしまうので、そういうものだと思って諦めるのも手でしょう。

方法2

参照を使うには、そのデータが既にメモリ上のどこかにそのままの形で存在している必要があります。方法2は入力バイト列中のデータをそのまま使う方法です。この方法は次のような注意点があります。

• 入力中に構造体のメモリレイアウト通りのデータがある場合だけ使える極めて限定的な方法です。
• B の中身として、基本的に整数や整数の固定長配列だけを扱えます。
• 2バイト以上の整数を使う場合、CPUによって違う挙動 (エンディアンの差異) が起きます。
• 2バイト以上の整数を使う場合、入力データのアドレスがきりのいい位置にある必要があります。 (アラインメント)
• serdeは色々なフォーマットをサポートしていますが、方法2が使えるのはzero-copy deserializationをサポートしているフォーマットだけです。そのようなフォーマットとしてmsgpack, bincodeなどがあります。(JSONなどでも文字列リテラルのzero-copy deserializationができますが、structにマップするのはまず無理でしょう。)
• シリアライズとの一貫性は自力で保証する必要があります。

エンディアン要件やアラインメント要件があるので、この方法が有益な場面は非常に限定されています。ELFのオブジェクトファイルのように、それ用に設計された(しかもアーキテクチャごとに固有の)ファイルフォーマットをmmapして使うケースがこの例にあたります。

メモリをstructにマップする処理を自分でやるとほぼ確実に未定義動作を踏むことになるので、bytemuckなど安全性を担保してくれるライブラリを使います。

use bytemuck::{try_cast_slice, Pod, Zeroable};
use serde::{Deserialize, Deserializer, Serialize};

#[derive(Clone, Copy, Serialize, Zeroable, Pod)]
#[repr(C)]
pub struct B {
    pub num: u32,
    pub level: i32,
    pub param: u32, // enumはPodにならないので使えない
}

#[derive(Serialize, Deserialize)]
struct A<'a> {
    // シリアライズとデシリアライズの一貫性は自力で保つ必要がある
    // (このコード例では省略している)
    #[serde(borrow, deserialize_with = "deserialize_b_slice")]
    data: &'a [B], // ここでエラー[E0227]
    index: usize,
}

fn deserialize_b_slice<'de, D>(de: D) -> Result<&'de [B], D::Error>
where
    D: Deserializer<'de>,
{
    // 実際にはunwrap()せずにD::Errorへの変換も実装するべきだが、今回は省略
    Ok(try_cast_slice(Deserialize::deserialize(de)?).unwrap())
}

方法3

どうしてもDeserializeに参照を吐かせなければいけない謎の理由がある場合、最終手段のひとつとしてメモリリークを許容するという手があります。

• この方法はメモリリークします。100%確実にメモリリークします。長時間起動するプログラムの初期化以外の部分で使ったら間違いなく問題になります。
• 結局アロケーションコストはかかるので、 Vec と比べてパフォーマンス上優位とは言えないでしょう。

use serde::{Deserialize, Deserializer, Serialize};

#[derive(Serialize, Deserialize)]
pub enum MyEnum {
    A,
    B,
    C,
    D,
    E,
}

#[derive(Serialize, Deserialize)]
pub struct B {
    pub num: u32,
    pub level: i32,
    pub param: MyEnum,
}

#[derive(Serialize, Deserialize)]
struct A<'a> {
    #[serde(deserialize_with = "deserialize_data_with_leak")]
    data: &'a [B], // ここでエラー[E0227]
    index: usize,
}

fn deserialize_data_with_leak<'a, 'de, D>(de: D) -> Result<&'a [B], D::Error>
where
    D: Deserializer<'de>,
{
    // !!! 100%メモリリーク !!!
    Ok(Vec::<B>::deserialize(de)?.leak())
}

方法4

serdeにはDeserializeSeedという、パラメーターつきのデシリアライズを行うためのトレイトがあります。Arenaをパラメーターに置いてデシリアライズすればArena管理下のメモリを指す参照を出力することができます。

use serde::de::{DeserializeSeed, SeqAccess, Visitor};
use serde::{Deserialize, Deserializer, Serialize};
use typed_arena::Arena;

#[derive(Serialize, Deserialize)]
pub enum MyEnum {
    A,
    B,
    C,
    D,
    E,
}

#[derive(Serialize, Deserialize)]
pub struct B {
    pub num: u32,
    pub level: i32,
    pub param: MyEnum,
}

#[derive(Serialize)]
struct A<'a> {
    data: &'a [B],
    index: usize,
}

struct DeserializeA<'a> {
    arena: &'a Arena<B>,
}

impl<'a, 'de> DeserializeSeed<'de> for DeserializeA<'a> {
    type Value = A<'a>;
    fn deserialize<D>(self, deserializer: D) -> Result<Self::Value, D::Error>
    where
        D: Deserializer<'de>,
    {
        struct AVisitor<'a> {
            arena: &'a Arena<B>,
        }
        impl<'a, 'de> Visitor<'de> for AVisitor<'a> {
            type Value = A<'a>;

            // mapなど他のvisitorも実装しないといけない
            fn visit_seq<SA>(self, mut seq: SA) -> Result<Self::Value, SA::Error>
            where
                SA: SeqAccess<'de>,
            {
                // 本当はunwrapせずにエラーハンドリングを書く必要がある
                let data: Vec<_> = seq.next_element()?.unwrap();
                let index = seq.next_element()?.unwrap();

                let data = self.arena.alloc_extend(data.into_iter());
                Ok(A { data, index })
            }

            fn expecting(&self, _f: &mut std::fmt::Formatter) -> std::fmt::Result {
                Ok(())
            }
        }
        deserializer.deserialize_struct("A", &["data", "index"], AVisitor { arena: self.arena })
    }
}

ただしDeserializeSeedのサポートは極めて限定的でserde-jsonすらサポートしていない状態です。また上の例では中間データとして Vec を使っているのでアロケーションコスト的にも有利ではなくメリットが薄いです。(個数が未知の配列をデシリアライズするための中間領域はどうしても必要になる)

またderive macro上もDeserializeと同等の使い勝手は望めないでしょう。こちらもほとんど最終手段だと思います。