Closure kind inference: infer whether a closure is Fn, FnMut, etc
#16640
Comments
|
P-backcompat-lang, 1.0. |
Part of issue rust-lang#16640. I am leaving this issue open to handle parsing of higher-rank lifetimes in traits. This change breaks code that used unboxed closures: * Instead of `F:|&: int| -> int`, write `F:Fn(int) -> int`. * Instead of `F:|&mut: int| -> int`, write `F:FnMut(int) -> int`. * Instead of `F:|: int| -> int`, write `F:FnOnce(int) -> int`. [breaking-change]
alexcrichton
changed the title
alexcrichton
changed the title
|
I've updated the title/description/tags to all reflect the remaining pieces to do for the RFC. As pointed out by @P1start in rust-lang/rfcs#451 this isn't fully done yet in terms of a tracking issue for the RFC. |
|
Can I expect the below code to work fn main() {
let x = 1i;
let f = move || {
move || { x+1 }
};
println!("{}", f()());
}once this issue is closed? |
|
assigning P-high, not blocking 1.0 milestone. |
|
Nominating; we should consider the beta milestone here IMO. |
|
Assigning 1.0-beta milestone to try to force this to get implemented for the beta. |
|
Note: this is likely required to nix the |
|
cc me |
nikomatsakis
changed the title
Fn, FnMut, etc
|
As of #21805 this is almost complete. The major to do item is described in that PR: "The interaction with instantiating type parameter fallbacks leaves something to be desired. This is mostly just saying that the algorithm from rust-lang/rfcs#213 needs to be implemented, which is a separate bug. There are some semi-subtle interactions though because not knowing whether a closure is Fn vs FnMut prevents us from resolving obligations like F : FnMut(...), which can in turn prevent unification of some type parameters, which might (in turn) lead to undesired fallback. We can improve this situation however -- even if we don't know whether (or just how) F : FnMut(..) holds or not for some closure type F, we can still perform unification since we do know the argument and return types. Once kind inference is done, we can complete the F : FnMut(..) analysis -- which might yield an error if (e.g.) the F moves out of its environment." |
|
cc #21843 |
This *almost* completes the job for rust-lang#16440. The idea is that even if we do not know whether some closure type `C` implements `Fn` or `FnMut` (etc), we still know its argument and return types. So if we see an obligation `C : Fn(_0)`, we can unify `_0` with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done. As part of this PR, the explicit `:` syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be `:` and may be some sort of generalization of the `||` syntax to handle other traits as well.) This commit does not *quite* fix rust-lang#16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit `&mut:` and friends. r? @eddyb as he reviewed the prior patch in this direction
Updated description
Closure kind inference: infer whether a closure is
Fn,FnMut, etcOriginal Description
Fn(int) -> int, etc.Nominating for 1.0, P-backcompat-lang.
The text was updated successfully, but these errors were encountered: