Blanket impls for &F/&mut F where F: Fn/F:FnMut respectively
#23895
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
context private.
… and onto the `UnificationTable`, and renaming/collapsing some methods.
so that it is closer to standalone.
trait matching more tailored. We now detect recursion where the obligations "match" -- meaning basically that they are the same for some substitution of any unbound type variables.
F`, so that if we have `x: &mut FnMut()`, then `x()` is translated to `FnMut::call_mut(&mut *x, ())` rather than `&mut x`. The latter would require `mut x: &mut FnMut()`, which is really a lot of mut. (Actually, the `mut` is normally required except for the special case of a `&mut F` reference, because that's the one case where we distinguish a unique path like `x` from a mutable path.)
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
|
Nice! |
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Apr 1, 2015
…dd-impls, r=pnkfelix
The primary purpose of this PR is to add blanket impls for the `Fn` traits of the following (simplified) form:
impl<F:Fn> Fn for &F
impl<F:FnMut> FnMut for &mut F
However, this wound up requiring two changes:
1. A slight hack so that `x()` where `x: &mut F` is translated to `FnMut::call_mut(&mut *x, ())` vs `FnMut::call_mut(&mut x, ())`. This is achieved by just autoderef'ing one time when calling something whose type is `&F` or `&mut F`.
2. Making the infinite recursion test in trait matching a bit more tailored. This involves adding a notion of "matching" types that looks to see if types are potentially unifiable (it's an approximation).
The PR also includes various small refactorings to the inference code that are aimed at moving the unification and other code into a library (I've got that particular change in a branch, these changes just lead the way there by removing unnecessary dependencies between the compiler and the more general unification code).
Note that per rust-lang/rfcs#1023, adding impls like these would be a breaking change in the future.
cc @japaric
cc @alexcrichton
cc @aturon
Fixes rust-lang#23015.
|
☔ The latest upstream changes (presumably #23955) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The primary purpose of this PR is to add blanket impls for the
Fntraits of the following (simplified) form:However, this wound up requiring two changes:
x()wherex: &mut Fis translated toFnMut::call_mut(&mut *x, ())vsFnMut::call_mut(&mut x, ()). This is achieved by just autoderef'ing one time when calling something whose type is&For&mut F.The PR also includes various small refactorings to the inference code that are aimed at moving the unification and other code into a library (I've got that particular change in a branch, these changes just lead the way there by removing unnecessary dependencies between the compiler and the more general unification code).
Note that per rust-lang/rfcs#1023, adding impls like these would be a breaking change in the future.
cc @japaric
cc @alexcrichton
cc @aturon
Fixes #23015.