-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Prohibit unused type parameters in impls. #447
Conversation
Would this change forbid any code that is currently in the Rust repo (either in the compiler or in the stdlib)? |
On Thu, Nov 06, 2014 at 08:49:12AM -0800, Thiez wrote:
I have not investigated. |
Does this apply to lifetime parameters? If so, this might prevent certain patterns: e.g. |
On Mon, Nov 10, 2014 at 06:55:47AM -0800, Joshua Yanovski wrote:
I imagine so, but it's less crucial.
I think such code can always be rewritten in a similar fashion to the |
The example I was thinking of was something like: struct Foo<'a> { foo: &'a () }
impl<'a: 'b, 'b> Foo<'a> {
fn bar(&'a self, foo: &'b ()) { /* ... */ }
}
fn main() {} The example is contrived but I'm not sure you can write it anymore (and I think I've written something similar at least once in the past where it wasn't contrived). I don't think you get the same problem with types because there's no analog for the outlives relation. |
On Tue, Nov 11, 2014 at 06:06:34AM -0800, Joshua Yanovski wrote:
This can be rewritten most explicitly as follows:
This rewrite requires full support for where clauses, which are not That said, the So in fact you could just drop the where clause and everything would |
Sure, I realized that for the initial example it was implied (which is why I hastily changed it!), I just meant there were situations where you couldn't write it. But if where clause syntax will support it, then I have no misgivings :) |
@arielb1 showed me a nice example of where we can encounter problems today, even without requiring the cross-crate scenario that was concerning me: http://is.gd/hZSQ2N |
During a conversation in IRC, @huonw raised an example that demonstrates that, with associated types, some type parameters that would appear unconstrained are in fact constrained:
Here |
This RFC has been accepted, as per the stated motivations. Lifetime parameters are not affected, however. |
Why is this not permitted under this RFC? trait Foo<T> { }
trait Bar { }
impl<T: Foo<U>, U> Bar for T { } |
@withoutboats because the type of Imagine that somebody just gave you the trait reference. In this case, that might be Within a given crate, you might infer that based on what impls exist -- but then imagine that other crates come along and add more impls. Now your inference is ambiguous. This is exactly the scenario in which the compiler finds itself, particularly with specialization at play. |
Thanks, that makes sense. |
typeck: use a TypeVisitor in ctp Use a TypeVisitor in ctp instead of `ty::walk` This fixes a few cases where a region could be projected out of a trait while not being constrained by the type parameters, violating rust-lang/rfcs#447 and breaking soundness. As such, this is a [breaking-change]. Fixes #35139 r? @eddyb
For well-defined semantics, we must ensure that impls do not have type parameters that do not appear within the trait or self-type.
Rendered view.