「AsRefを入力とする関数」を引数に取る関数の呼び出しでコンパイルエラーになる理由・ならない理由が分からない

Question

前提・実現したいこと

参照の引数を持つ関数を別の関数に渡したいの中で何故かクロージャーを渡した場合にコンパイルが通る理由が分かりませんでした。
以下のように1~4まで試してみましたが、何故か2と3はコンパイルエラーとなりました。特に3と4はなぜ差が出るのが検討もつきませんでした。

発生している問題・エラーメッセージ

   Compiling playground v0.0.1 (/playground)
error[E0631]: type mismatch in function arguments
  --> src/main.rs:20:22
   |
5  | fn f2<T: AsRef<[u32]>>(input: T) -> u32 {
   | --------------------------------------- found signature of `fn(_) -> _`
...
9  | fn g<F: Fn(&[u32]) -> u32>(func: F) -> u32 {
   |         ----------------- required by this bound in `g`
...
20 |     println!("{}", g(f2));
   |                      ^^ expected signature of `for<'r> fn(&'r [u32]) -> _`

error[E0271]: type mismatch resolving `for<'r> <fn(_) -> u32 {f2::<_>} as std::ops::FnOnce<(&'r [u32],)>>::Output == u32`
  --> src/main.rs:20:20
   |
9  | fn g<F: Fn(&[u32]) -> u32>(func: F) -> u32 {
   |                       --- required by this bound in `g`
...
20 |     println!("{}", g(f2));
   |                    ^ expected bound lifetime parameter, found concrete lifetime

error[E0631]: type mismatch in closure arguments
  --> src/main.rs:24:22
   |
9  | fn g<F: Fn(&[u32]) -> u32>(func: F) -> u32 {
   |         ----------------- required by this bound in `g`
...
23 |     let h = |x| f2(x);
   |             --------- found signature of `fn(_) -> _`
24 |     println!("{}", g(h));
   |                      ^ expected signature of `for<'r> fn(&'r [u32]) -> _`

error[E0271]: type mismatch resolving `for<'r> <[closure@src/main.rs:23:13: 23:22] as std::ops::FnOnce<(&'r [u32],)>>::Output == u32`
  --> src/main.rs:24:20
   |
9  | fn g<F: Fn(&[u32]) -> u32>(func: F) -> u32 {
   |                       --- required by this bound in `g`
...
24 |     println!("{}", g(h));
   |                    ^ expected bound lifetime parameter, found concrete lifetime

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0271, E0631.
For more information about an error, try `rustc --explain E0271`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.

該当のソースコード

fn f1(input: &[u32]) -> u32 {
    input[0]
}

fn f2<T: AsRef<[u32]>>(input: T) -> u32 {
    input.as_ref()[0]
}

fn g<F: Fn(&[u32]) -> u32>(func: F) -> u32 {
    let input = vec![1, 2, 3];
    let output = func(&input);
    output
}

fn main() {
    // 1. ok
    println!("{}", g(f1));

    // 2. error
    println!("{}", g(f2));

    // 3. error
    let h = |x| f2(x);
    println!("{}", g(h));

    // 4. ok
    println!("{}", g(|x| f2(x)));
}

補足情報（FW/ツールのバージョンなど）

コードはRust Playgroundにもあります。

Answer 1

HRTBまわりの問題だと思われます。HRTBまわりの挙動はぼくも正確に理解できているわけではないのですが、以下の推測で大きくは外していないと思います。

まず関数 g が受け取っている F の制約。ここは fn 以外で特別にlifetime elisionが有効な箇所で、展開すると以下のような制約になります。

// オリジナル
fn g<F: Fn(&[u32]) -> u32>(func: F) -> u32;
// lifetime elisionの展開後
fn g<F: for<'a> Fn(&'a [u32]) -> u32>(func: F) -> u32;
// forを手前に持ってくる
fn g<F>(func: F) -> u32
where
    for<'a> F: Fn(&'a [u32]) -> u32;

つまり、「任意の 'a に対して F: Fn(&'a [u32]) -> u32 が成立していること」がここでは求められています。

このようにライフタイムに関する高階の制約をRustではある程度扱うことができますが、この部分の動作はかなりアドホックです。

fn main() {
    // ライフタイム量化の削除は可能
    let f: fn(&str) -> &[u8] = AsRef::as_ref;
    let f: fn(&'static str) -> &'static [u8] = AsRef::as_ref;

    // ライフタイム量化が増えるような変換は不可能 (意味的に可能であっても)
    let f: fn(i32) -> i32 = std::convert::identity;
    // let f: fn(&i32) -> &i32 = std::convert::identity; // error

    // fn/クロージャを作成するタイミングで量化を増やせるので、η展開すれば量化を増やせる
    let f: fn(&i32) -> &i32 = |x| std::convert::identity(x);
}

コンパイラの実装上は、 identity を見つけたときにその型引数に型変数を代入することで型推論を行います。上記の // error と書いてあるコードが通るためにはこのとき for<'a> ?A<'a> という形の型変数を作る必要がありますが、そうはしません。理由は正確にはわかりませんが、このように式の出現でいちいち量化を検討すると問題が複雑になり、コンパイラパフォーマンスにも影響があるのではないかと思います。

ではどこでは量化が可能なのか。関数定義ではいつも以下のように普通に使っていると思いますが……

// ライフタイムに関して量化されている
fn foo(s: &str) -> &[u8];
// fn foo<'a>(s: &'a str) -> &'a [u8];

クロージャでも同様にライフタイムによる量化が可能になっています。ただし、この場合は引数型が省略できるので、何らかの方法で「どう量化するべきか」を推測できる必要があります。

fn foo<'a>(i: &'a i32) -> &'a i32 {
    // このfは以下のどちらかだが、これを確定する根拠はない (どちらにも合理性がある):
    // f: impl Fn(&'a i32) -> &'a i32
    // f: impl for<'b> Fn(&'b i32) -> &'b i32
    let f = |j| j;
    f(i)
}

実際にどちらに推測されたかは、以下のように書いてみればわかります。

fn foo<'a>(i: &'a i32) -> &'a i32 {
    let f = |j| j;
    let result = f(i);
    
    let x = 42;
    f(&x); // error

    result
}

上記の場合は単相に推論されたことがわかります。

一方、 f の型として多相な関数ポインタ型を指定していると、多相に推論されます。

fn foo<'a>(i: &'a i32) -> &'a i32 {
    let f: fn(&i32) -> &i32 = |j| j;
    let result = f(i);
    
    let x = 42;
    f(&x); // OK

    result
}

Rustの型推論では、トップダウンに「期待する型」を伝搬することで、このようなアドホックな処理のヒントにしています (型強制を行うタイミングの決定などにも使っている)。上記の例では、「期待する型」が関数ポインタであるときに、それを利用して多相性を推論しているのだと考えられます。

---

あらためて元の問題に戻ると、

• 2のケースでは、 f2 の T には特定のライフタイムが入った単相型 &'_ u32 が代入される。こうして得られた関数は g が期待する型 (impl for<'a> Fn(&'a [i32]) -> i32) と互換ではないのでエラーになっている。
• 3～4のケースではクロージャで挟まれることで、この部分でライフタイム量化が期待通りに処理される可能性が生じる。しかしクロージャのライフタイム量化はアドホックに決定されるので、型のヒントが適切に与えられている4のケースのみ通る

と考えられます。

Comments

[Toru3]

なるほど、多相なものを要求しているところに単相なものを渡しているからエラーになっていて、3のケースではhに代入した時点で単相に推論されてしまうのでエラーになるということですね。そして4はクロージャーの生成時に増せる量化がうまく働いて多相なものとして渡るのでエラーにならないということですね。確かに3で多相な関数ポインタ型を指定するとエラーになりませんでした。
スッキリしました。ありがとうございます。