-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type inference insufficient around trait parameterized functions #3156
Comments
I agree this would be nice to fix. Considering your points in reverse order:
Moreover, even if we had higher-kinded types, I am not sure that
|
To clarify what I wrote about higher-kinded types and inference: what I meant is that somewhere (the impl, I suppose) we'd have to define how |
Stabilize backtrace This PR stabilizes the std::backtrace module. As of rust-lang#99431, the std::Error::backtrace item has been removed, and so the rest of the backtrace feature is set to be stabilized. Previous discussion can be found in rust-lang#72981, rust-lang#3156. Stabilized API summary: ```rust pub mod std { pub mod backtrace { pub struct Backtrace { } pub enum BacktraceStatus { Unsupported, Disabled, Captured, } impl fmt::Debug for Backtrace {} impl Backtrace { pub fn capture() -> Backtrace; pub fn force_capture() -> Backtrace; pub const fn disabled() -> Backtrace; pub fn status(&self) -> BacktraceStatus; } impl fmt::Display for Backtrace {} } } ``` `@yaahc`
We had a spurious update attempt logged in rust-lang#3155 for the job prior to this fix would empty out the version strings. This was caused by use of undefined variables. Resolves: rust-lang#3155 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses. Co-authored-by: Adrian Palacios <73246657+adpaco-aws@users.noreply.github.com> Co-authored-by: Zyad Hassan <88045115+zhassan-aws@users.noreply.github.com>
This is related to #912.
The following code doesn't work:
It fails with
which is really unfortunate.
eachi
is declared with the prototypefn eachi<A,IA:base_iter<A>>(vec: IA, blk: fn(uint, A) -> bool)
. When called in the above code, IA is instantiated with the typeoption<{a: int}>
, and a note is made thatoption<{a: int}>
must implement the traitbase_iter<A>
. However, without knowing the details of the implementation, there is no way to know that the onlyA
such thatoption<{a: int}>
implementsbase_iter<A>
is{a: int}
.I can think of a couple of possible solutions, varying wildly in feasibility:
Do some sort of opportunistic impl search during typechecking, probably in some super ad-hoc place such as during function argument typechecking, after checking the non-closure arguments but before checking closure arguments. This is not particularly principled but might be pretty feasible.
Introduce proper higher kinded type variables and traits over them. Then traits wouldn't be parameterized over type variables but would instead be implemented for higher kinds. The signature of
eachi
would befn eachi<A,IA:base_iter>(vec: IA<A>, blk: fn(uint, A) -> bool)
andIA<A>
would be unified withoption<{a: int}>
right off the bat.Fix issue Block type-inference sometimes fails #912 so that the type isn't needed while typechecking the closure.
The text was updated successfully, but these errors were encountered: