奇怪地重复出现的通用特征模式:溢出评估需求
我正在尝试实现一个具有一堆字段的泛型结构，其中每个字段类型都应该知道整个结构的确切类型。这是一种策略模式。
pub struct Example<S: Strategy<Example<S, D>>, D> {
pub s: S,
pub a: S::Associated,
pub data: D,
}
pub trait Strategy<T> {
type Associated;
fn run(&self, &T);
}
pub trait HasData {
type Data;
fn data(&self) -> &Self::Data;
}
impl<S: Strategy<Self>, D> Example<S, D> {
// ^^^^
// the complex code in this impl is the actual meat of the library:
pub fn do_it(&self) {
self.s.run(self); // using the Strategy trait
}
}
impl<S: Strategy<Self>, D> HasData for Example<S, D> {
type Data = D;
fn data(&self) -> &D {
&self.data
}
}然后我打算从上面的“库”中实例化泛型：
pub struct ExampleStrat;
pub struct ExampleData;
impl<E: HasData<Data = ExampleData>> Strategy<E> for ExampleStrat {
type Associated = ();
fn run(&self, e: &E) {
let _ = e.data();
// uses ExampleData here
}
}
let example = Example {
s: ExampleStrat,
a: (),
data: ExampleData,
};
example.do_it();在我的实际代码中，我有很多不同的“策略”和多个数据字段，所以Example类型有一个令人印象深刻的泛型列表，如果库用户不需要明确说明它们(或者至少不经常)，而只需要使用HasData特征(及其相关类型，而不是泛型类型参数)，我会很高兴。
如果struct Example<S, D>中没有类型绑定，这实际上(令人惊讶地)会工作得很好，比我最初预期的(在fighting with Self in the struct bounds之后)要好得多。然而，当结构应该只与受约束的类型一起使用时，建议使用duplicate the impl trait bounds on the struct，在我的例子中，我实际上需要它们能够将Associated类型用于a字段。
现在编译器正在抱怨
error[E0275]: overflow evaluating the requirement `main::ExampleStrat: Strategy<Example<main::ExampleStrat, main::ExampleData>>`
--> src/main.rs:42:9
|
42 | a: (),
| ^^^^^
|
= note: required because of the requirements on the impl of `HasData` for `Example<main::ExampleStrat, main::ExampleData>`
= note: required because of the requirements on the impl of `Strategy<Example<main::ExampleStrat, main::ExampleData>>` for `main::ExampleStrat`我怎么才能解决这个问题呢？我是不是在尝试做一些不可能的事情，我是不是做错了，或者这应该是可能的，但我却成了a compiler bug的牺牲品？我的整个设计有缺陷吗？
回答 2
Stack Overflow用户
发布于 2018-06-02 22:41:10
首先，如果避免在结构和特征的定义上定义特征，那么一切都会变得清晰得多。当事情变得复杂时，约束至少是从同一个方向解决的。
pub struct Example<S, D, A> {
pub s: S,
pub a: A,
pub data: D,
}
pub trait Strategy<T> {
type Associated;
fn run(&self, &T);
}
pub trait HasData {
type Data;
fn data(&self) -> &Self::Data;
}
impl<S, D, A> Example<S, D, A>
where
S: Strategy<Self, Associated = A>,
{
pub fn do_it(&self) {
self.s.run(self);
}
}
impl<S, D, A> HasData for Example<S, D, A>
where
S: Strategy<Self, Associated = A>,
{
type Data = D;
fn data(&self) -> &D {
&self.data
}
}用于ExampleStrat的Strategy实现如下所示：
impl<E: HasData<Data = ExampleData>> Strategy<E> for ExampleStrat {
type Associated = ();
// ...
}这意味着您正在为所有可能的限定类型E定义它。类型检查器现在只能查看特征边界，这些边界也是通用的，并且只能用其他特征来表示，这些特征相互使用作为边界，因此类型检查器进入循环。在循环中添加一个块，给它一个具体的类型，这是你知道的。
pub struct ExampleStrat;
pub struct ExampleData;
impl Strategy<Example<ExampleStrat, ExampleData, ()>> for ExampleStrat {
type Associated = ();
fn run(&self, e: &Example<ExampleStrat, ExampleData, ()>) {
let _ = e.data();
// uses ExampleData here
}
}
fn main() {
let example = Example {
s: ExampleStrat,
a: (),
data: ExampleData,
};
example.do_it();
}Stack Overflow用户
发布于 2018-06-03 04:50:07
如果下面的impl是Strategy特有的，那么它可能被参数化到了错误的地方。(对于这个答案，我将忽略相关的类型，因为示例中没有使用它。)
impl<E: HasData<Data = ExampleData>> Strategy<E> for ExampleStrat {
fn run(&self, e: &E) {
let _ = e.data();
// uses ExampleData here
}
}相反，您可以参数化D上的Strategy --打破impl依赖循环--并且只参数化E上的run方法。
pub trait Strategy<D> {
fn run(&self, &impl HasData<Data = D>);
}
impl Strategy<ExampleData> for ExampleStrat {
fn run(&self, e: &impl HasData<Data = ExampleData>) {
let _ = e.data();
// uses ExampleData here
}
}fn run<E: HasData<Data = ExampleData>>(&self, e: &E)是定义与此目的相同的run的另一种方式。Here is a full example。
这种方法的一个潜在缺点是不能通过Strategy特征对象调用run，因为对于实现HasData的任何类型，都必须将其单一化。但是HasData特性在这个impl中似乎作用不大:它唯一能做的就是返回一个内部引用，一旦有了它，再使用它就没有意义了。也许run可以参考一下&D？
pub trait Strategy<D> {
fn run(&self, &D);
}
impl Strategy<ExampleData> for ExampleStrat {
fn run(&self, _: &ExampleData) {
// uses ExampleData here
}
}可以肯定的是，现在你必须在do_it中调用self.s.run(self.data())，但这并不会降低你对原始版本的灵活性，在原始版本中，如果它正常工作，你只能使用&E类型的参数来调用Strategy<E>::run。
实际上，对我来说，整个HasData特征似乎没有必要:它总是由调用它的同一类型实现的，所以除了传递self而不是self.data带来的便利之外，它不会提升do_it方法内部的抽象级别。因此，在我看来，对delete HasData entirely和让Example知道如何使用正确的引用调用Strategy::run也是一样的事情；不管怎样，它必须这样做。(然而，有可能我只是缺乏想象力。)
这些解决方案中的任何一个都应该处理向Strategy添加关联类型，但是由于不知道它将如何使用，所以很难确定。
²它可以在编译器的未来版本中工作，并具有足够智能的类型检查。
https://stackoverflow.com/questions/50657585
复制相似问题