Methods behind a feature gate are still visible to the compiler even when the feature is not on

[mlalic]

When a new trait method is found behind a feature gate (such as the read_exact method of io::Read, which is behind the correspondingly named feature) rustc will see the method in scope even if the feature has not been explicitly turned on for the crate.

This causes a problem when a different trait has a method with the same name as the newly added one. I would expect that rustc should not even "see" the method in scope if it has not been explicitly asked for by flipping the feature gate?

The following code snippet demonstrates the issue on the current nightly (rustc 1.4.0-nightly (fe9cef7da 2015-08-30)).

use std::io;

trait MyExt: io::Read {
    fn read_exact(&mut self, buf: &mut [u8]) -> io::Result<()> {
        // Real implementation would go here...
        Ok(())
    }
}

impl<T> MyExt for T where T: io::Read {}

fn foo<R: MyExt>(mut r: R) {
    let mut target = [0; 2];
    r.read_exact(&mut target).unwrap();
    println!("{:?}", target);
}

fn main() {
    let mut buf: &[u8] = &[1, 2, 3, 4, 5];
    foo(&mut buf);
}

The compiler would say that there are multiple applicable items in scope for the read_exact method (the one from MyExt and the one from io::Read), but the method on io::Read is not really applicable in this case -- it would require #![feature(read_exact)], which is not used here. It is also, in my opinion, slightly strange for the introduction of a trait method behind a feature gate to break a build when no one requested the feature be used... Therefore, I would expect the code given here to compile all right as long as #![feature(read_exact)] is not used.

Is it possible for the compiler to resolve names after considering the features that are used or is this inherently "working as intended"?

[nikomatsakis]

We discussed this back when feature-gate system was being first put into place. The decision was that it was better to have advance notice of upcoming method-name conflicts, and hence we decided not to alter the behavior. (In some cases, when the resulting problems are widespread, we have rolled back changes or renamed methods as a result, as well.) Therefore, I'm going to close this issue. Thanks though for the report.

(That said, it seems to that the ideal might be to issue warnings, but that would be more complex to implement.)