Skip to content

RFC: Allow inference of argument/return value in trait impls #12468

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

Closed
huonw opened this issue Feb 22, 2014 · 2 comments
Closed

RFC: Allow inference of argument/return value in trait impls #12468

huonw opened this issue Feb 22, 2014 · 2 comments
Labels
A-type-system Area: Type system

Comments

@huonw
Copy link
Member

huonw commented Feb 22, 2014

From reddit.

The trait definition entirely determines the signatures of impl'd methods, and so the signature is known without examining the function body, e.g.

trait Foo<T> { fn bar(&self, x: T, y: Self, z: ~str) -> bool; }

impl Foo<int> for f64 {
     fn bar(&self, x: int, y: f64, z: ~str) -> bool { ... }
}
// could be
impl Foo<int> for f64 {
     fn bar(&self, x, y, z) { ... }
}

(Or something like fn bar(&self, x: _, y: _, z: _) -> _ { ... } to make it obvious that a inferred/blank type is being used.)


I'm personally ambivalent on this; it may result in

  • some tooling being harder to write,
  • confusing error messages,
  • code that subtly changes behaviour if an upstream trait changes method definitions slightly, but the method body uses that argument in a way that is satisfied by both the old and new types. e.g. TreeMap<uint, T> becoming ~[T]: they both have a methods called insert and remove with the same signature, but they have different performance and semantics. (WIth explicit signatures, the downstream code would stop compiling, rather than changing behaviour.)
@glaebhoerl
Copy link
Contributor

FWIW, another somewhat similar case is items declared inside fns. Theoretically if you have an fn or static declared inside the body of an fn, you could infer its type without breaking the principle of "no type inference at the API level". It probably doesn't make much difference from the perspective of complicating the type inference algorithm, though. (This is different from the case in the OP in that this is actually type inference, while that's something much simpler: just instantiating type parameters.)

My personal feeling w.r.t. both of these is that they're interesting possibilities but also tremendously unimportant, i.e.: I don't feel like we need to make a decision either way, we can just note the possibility (as we have) and come back to it (much) later when we don't have way more important things to think about.

@rust-highfive
Copy link
Contributor

This issue has been moved to the RFCs repo: rust-lang/rfcs#309

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
minor: Don't log cancelled diagnostics

Since we retry requests now we can actually hit this legitimately
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
Projects
None yet
Development

No branches or pull requests

3 participants