Skip to content
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

Closed
msullivan opened this issue Aug 8, 2012 · 2 comments
Closed

Type inference insufficient around trait parameterized functions #3156

msullivan opened this issue Aug 8, 2012 · 2 comments
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@msullivan
Copy link
Contributor

This is related to #912.

The following code doesn't work:

fn main() {
    for iter::eachi(some({a: 0})) |i, a| { 
        #debug["%u %d", i, a.a];
    }
}

It fails with

nubs/closure-trait-infer.rs:3:27: 3:30 error: the type of this value must be known in this context
nubs/closure-trait-infer.rs:3         #debug["%u %d", i, a.a];

which is really unfortunate.

eachi is declared with the prototype fn eachi<A,IA:base_iter<A>>(vec: IA, blk: fn(uint, A) -> bool). When called in the above code, IA is instantiated with the type option<{a: int}>, and a note is made that option<{a: int}> must implement the trait base_iter<A>. However, without knowing the details of the implementation, there is no way to know that the only A such that option<{a: int}> implements base_iter<A> is {a: int}.

I can think of a couple of possible solutions, varying wildly in feasibility:

  1. 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.

  2. 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 be fn eachi<A,IA:base_iter>(vec: IA<A>, blk: fn(uint, A) -> bool) and IA<A> would be unified with option<{a: int}> right off the bat.

  3. Fix issue Block type-inference sometimes fails #912 so that the type isn't needed while typechecking the closure.

@ghost ghost assigned msullivan Aug 8, 2012
@nikomatsakis
Copy link
Contributor

I agree this would be nice to fix. Considering your points in reverse order:

  • I think Block type-inference sometimes fails #912 is a non-starter. I closed it.
  • It's not obvious to me how higher-kinded types solves this problem. I think the problem has to do with the fact that we do not connect type parameters. That is to say, I don't think that unifying IA<A> with option<{f: int}> would necessarily equate A with {f: int}. I guess it depends on how flexible our system was, but I could imagine a higher-kinded type option<{f: _}> or foo<str, _>. In the latter case, the value would be foo<str, {f: int}> (not option<int>). So how could I unify foo<str, {f: int}> with IA<A> (not knowing what IA is) and extract a value for A?

Moreover, even if we had higher-kinded types, I am not sure that iterable would be a suitable place to use it. Defining iterable that way would rule out a type like BitSet from implementing iterable<int> and no other type.

  • That leaves us with determining ifaces earlier rather than later. I would like to experiment with this but I do recall that the last time we talked it through there were complications, though I can't recall what they were. I guess the best thing to do is to read up more carefully on what Haskell does. If memory serves---and I could be wrong, I don't know Haskell very well---this particular problem that we are talking about is also related to functional dependencies: that is, we would like to be able to say that each iterable thing is only iterable over one type, and therefore if we know the value for IA, we can deduce the value for A. I think this relates to overloading: conceivably (in today's system) there could be a type empty_iterable which is defined for all A, for example, which would not help us in deducing the type of A.

@nikomatsakis
Copy link
Contributor

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 IA<A> is mapped to the concrete self type for this impl. I think implicit in your point was an assumption that, to implement an interface with one type parameter, you must supply a nominal type with one parameter. And maybe this is the right way to do it, but it's not the only way to do it.

@msullivan msullivan removed their assignment Jun 16, 2014
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 10, 2022
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`
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

2 participants