我可以避免急于解决使用泛型的特征实现的歧义吗? [英] Can I avoid eager ambiguity resolution for trait implementations with generics?

问题描述

请考虑以下Rust代码[游乐场]:

Consider the following Rust code [playground]:

use std::collections::HashMap;
use std::hash::Hash;

trait Foo<K> {
    const FOO: i32;
}

impl<K, K_, V> Foo<HashMap<K_, V>> for HashMap<K, V>
where
    K: Hash + Eq + Into<K_>,
{
    const FOO: i32 = 1;
}

impl<K, V, V_> Foo<HashMap<K, V_>> for HashMap<K, V>
where
    K: Hash + Eq,
    V: Into<V_>,
{
    const FOO: i32 = 2;
}

fn main() {}

(const不相关，我也想用fn s编译代码).

(The const is not relevant, I'd like the code to compile with fns too).

它无法编译并显示错误:

It fails to compile with the error:

error[E0119]: conflicting implementations of trait `Foo<std::collections::HashMap<_, _>>` for type `std::collections::HashMap<_, _>`:
  --> src/main.rs:15:1
   |
8  | / impl<K, K_, V> Foo<HashMap<K_, V>> for HashMap<K, V>
9  | | where
10 | |     K: Hash + Eq + Into<K_>,
11 | | {
12 | |     const FOO: i32 = 1;
13 | | }
   | |_- first implementation here
14 | 
15 | / impl<K, V, V_> Foo<HashMap<K, V_>> for HashMap<K, V>
16 | | where
17 | |     K: Hash + Eq,
18 | |     V: Into<V_>,
19 | | {
20 | |     const FOO: i32 = 2;
21 | | }
   | |_^ conflicting implementation for `std::collections::HashMap<_, _>`

据我了解，问题在于这里存在歧义-如果 都是合法的，应该选择哪种实现?理想情况下，我希望具有以下条件:

As I understand it, the problem is that there is an ambiguity here - which implementation should be picked if both are legal? Ideally I'd like to have the following:

1. 上面的代码(或一些解决方法)应该可以正常编译.
2. 在呼叫站点，如果给定类型只有一个impl，那么将选择该类型.
3. 在呼叫站点，如果有多个impl可能，那么这是一个错误(一致性问题).

1. The above code (or some work around) should compile fine.
2. At the call site, if there is only one impl possible for the given type, then that one is picked.
3. At the call site, if there are multiple impls possible, then it is an error (coherence issues).

更简洁地说，我想在呼叫站点而不是在定义站点进行歧义解决.可能有这种行为吗?

More succinctly, I want ambiguity resolution to be done at the call site, rather than at the definition site. Is it possible to have this behavior?

推荐答案

实际上，您可以在此处应用技巧.

There is, in fact, a trick you may be able to apply here.

为了使编译器为您 pick 一个impl，必须将其附加到可以推断的类型参数上.您可以将类型参数添加到trait Foo并创建标记结构，以使impl不再重叠:

In order for the compiler to pick an impl for you, it has to be attached to a type parameter that can be inferred. You can add a type parameter to trait Foo and create marker structs so that the impls no longer overlap:

trait Foo<K, U> {
    const FOO: i32;
}

struct ByKeyInto;
impl<K, K_, V> Foo<HashMap<K_, V>, ByKeyInto> for HashMap<K, V>
where
    K: Hash + Eq + Into<K_>,
{
    const FOO: i32 = 1;
}

struct ByValInto;
impl<K, V, V_> Foo<HashMap<K, V_>, ByValInto> for HashMap<K, V>
where
    K: Hash + Eq,
    V: Into<V_>,
{
    const FOO: i32 = 2;
}

由于Foo<_, ByKeyInto>和Foo<_, ByValInto>是不同的特征，因此impl不再重叠.当您使用对某些U要求Foo<_, U>的通用函数时，编译器可以寻找一种有效的类型，并且如果只有一种可能，则可以 解析为具体的类型.

Since Foo<_, ByKeyInto> and Foo<_, ByValInto> are different traits, the impls no longer overlap. When you use a generic function that requires Foo<_, U> for some U, the compiler can go looking for a type that works, and it does resolve to a concrete type if there is provably only one possibility.

下面是一个代码示例，该示例通过为U选择ByKeyInto或ByValInto在每个调用站点上编译并推断正确的impl:

Here's an example of code that compiles and infers the correct impl at each call site by picking ByKeyInto or ByValInto for U:

fn call_me<T, U>(_: T)
where
    T: Foo<HashMap<String, i32>, U>,
{
    println!("{}", T::FOO);
}

fn main() {
    let x: HashMap<&str, i32> = HashMap::new();
    call_me(x);
    let y: HashMap<String, bool> = HashMap::new();
    call_me(y);
}

这会打印(游乐场):

1
2

---

但是，由于Into是自反的(也就是说，T为所有T实现Into<T>)，因此如果要对HashMap<K, V>使用Foo<HashMap<K, V>>，则这很尴尬.由于在这种情况下，有 个重叠的impl，因此您必须通过turbofish(::<>)选择一个.

---

However, since Into is reflexive (that is, T implements Into<T> for all T), this is awkward if you want to use Foo<HashMap<K, V>> for HashMap<K, V>. Since there are overlapping impls in this case, you have to choose one by turbofish (::<>).

let z: HashMap<String, i32> = HashMap::new();
call_me::<_, ByKeyInto>(z);  // prints 1
call_me::<_, ByValInto>(z);  // prints 2

这篇关于我可以避免急于解决使用泛型的特征实现的歧义吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！