Open panstromek opened 2 years ago
@csmoe That doesn't seem like the same issue, because https://github.com/rust-lang/rust/issues/41078 talks about inferred types of closures, but here the problem is with a free function, not a closure. The problem doesn't seem to be an inference, but coercion.
Your fn cb1(_s: &S) -> bool is also sugar, for fn cb1<'a>(_s: &'a S) -> bool, so you get that same for<'a> aspect ahead of the filter(cb1).
fn(_: &Arg)
and Fn(&Arg)
"share" the same higher rank trait bound as for<'a> fn(&'a Arg)
cc https://rust-lang.github.io/rfcs/0387-higher-ranked-trait-bounds.html, so let alone the closure/function words in the comment.
The problem here is that drop is generic, so it can't even express such a bound because the reference is just <T>
in drop's definition. Is that really the same issue as incorrect type inference of a closure? I still don't see the connection.
I tried this code:
I expected to see this happen: I expect the code to compile. It looks like this should work, because drop should be more or less equivalent to toilet closure, it just has generic argument, but without any bounds, so it seems like it should be accepted here.
Instead, this happened:
Code doesn't compile with:
Meta
rustc --version --verbose
: