triage: I-nominated
I think this is fundamentally caused by the following compiling, which seems fairly bad:
struct Foo; impl Foo { fn id() {} } impl Foo { fn id() {} } fn main() {}
Putting both id's in the same impl fails to compile, as does trying to call Foo::id().
id
impl
Foo::id()
A lot of library types have .into_inner methods, but I’m not sure we’ve ever explicitly decided that we should do it for any adaptor type like this (e.g. should the various iterator adaptors get .into_inners?), especially ones like this where &mut/.by_ref work for some/most(?) cases.
.into_inner
&mut
.by_ref
triage: P-medium
triage: P-high
The high priority is just to investigate and make sure we understand what is going on.
(it is questionable about whether this should be classified as a "regression" per se, in terms of what the impact actually is of this sort of change if you aren’t opting into stronger lint settings. but anyway, we want to handle this case better.)
current hypothesis is that this represents a bug fix.
Nonetheless, triaging as P-medium to investigate and confirm that hypothesis.
someone should indeed try to figure out what the problem is; whether the test case in the previous comment is a representative (i.e. try it against Rust 1.4 or so), et cetera.
I was able to confirm that the code fails to compile on `rustc 1.5.0 (3d7cd77e4 2015-12-04)` but compiles on `rustc 1.4.0 (8ab8581f6 2015-10-27)`.
On January 7, 2016 7:07:41 PM GMT-02:00, Felix S Klock II wrote: >triage: P-high > >someone should indeed try to figure out what the problem is; whether >the test case in the previous comment is a representative (i.e. try it >against Rust 1.4 or so), et cetera. > >— >Reply to this email directly or view it on GitHub: >https://github.com/rust-lang/rust/issues/30744#issuecomment-169805274
Can the bot learn to escape these? The true title is:
Implement From<[T; ..]> for (T, ..) and From<(T, ..)> for [T; ..]
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.