Question

想象一下一些事件源，它产生表示为枚举的事件。当然，为了获得最佳效率，该生产者是零拷贝，即它返回对其内部缓冲区的引用：

enum Variant<'a> {
    Nothing,
    SomeInt(u64),
    SomeBytes(&'a [u8])
}

impl Producer {
    fn next(&'a mut self) -> Variant<'a> { ... }
}

对于不需要前瞻或回溯的消费者来说，这是完全正常的，但有时需要保存一些事件序列。因此，我们的Variant类型变为通用：

enum Variant<BytesT> {
    Nothing,
    SomeInt(u64),
    SomeBytes(BytesT)
}

type OwnedVariant = Variant<Vec<u8>>;
type BorrowedVariant<'a> = Variant<&'a [u8]>;

在这里，我们最终得到两种具有“所有者 - 参考”关系的类型，类似于对Vec<T> - &[T]，String - &str。文档建议内置特征Borrow和ToOwned提供除了微妙的细微差别之外所需要的内容：

trait Borrow<Borrowed: ?Sized> {
    fn borrow(&self) -> &Borrowed;
    // this: -----------^
}

pub trait ToOwned {
    type Owned: Borrow<Self>;
    fn to_owned(&self) -> Self::Owned;
}

borrow的结果必须是对的引用，BorrowedVariant<'a>显然不是。删除此要求可以解决此问题（此处，名称以 alt 为前缀，以强调这是另一种接口）：

trait AltBorrow<'a, AltBorrowed> { fn alt_borrow(&'a self) -> AltBorrowed; } trait AltToOwned<'a> { type AltOwned: AltBorrow<'a, Self>; fn alt_to_owned(&'a self) -> Self::AltOwned; }

然后可以针对标准类型实现该特征，例如Vec：

impl<'a, T> AltBorrow<'a, &'a [T]> for Vec<T> { fn alt_borrow(&'a self) -> &'a [T] { self.as_slice() } } impl<'a, T> AltToOwned<'a> for &'a [T] where T: Clone { type AltOwned = Vec<T>; fn alt_to_owned(&'a self) -> Vec<T> { self.to_vec() } }

以及有问题的Variant枚举：

impl<'a> AltBorrow<'a, BorrowedVariant<'a>> for OwnedVariant { fn alt_borrow(&'a self) -> BorrowedVariant<'a> { match self { &Variant::Nothing => Variant::Nothing, &Variant::SomeInt(value) => Variant::SomeInt(value), &Variant::SomeBytes(ref value) => Variant::SomeBytes(value.alt_borrow()), } } } impl<'a> AltToOwned<'a> for BorrowedVariant<'a> { type AltOwned = OwnedVariant; fn alt_to_owned(&'a self) -> OwnedVariant { match self { &Variant::Nothing => Variant::Nothing, &Variant::SomeInt(value) => Variant::SomeInt(value), &Variant::SomeBytes(value) => Variant::SomeBytes(value.alt_to_owned()), } } }

最后，问题：

我是否滥用了原来的Borrow / ToOwned概念？我应该用其他东西来达到这个目的吗？

如果没有，那么为什么可能首选来自std::borrow的当前不太通用的界面的原因是什么？

This example on Rust playpen

Answer 1

在#rust IRC上获得some explanation。

来自 aturon ：

  简短的回答是：我们需要更高级别的类型（HKT）来做得更好;应该可以在以后顺利“升级”到HKT，但

（这是一种在标准库中出现的模式）

（将生命周期提升到特质水平是对HKT进行编码的一种方式，但使得使用该特征更加尴尬）

来自 bluss ：

我喜欢你的问题。 IMO已经没有充分探索这种特质的生命但它现在在借用检查器中也有一个已知的错误

为什么Borrow特征要求借用的类型作为参考？

1 个答案: