Enum variants completely shadow inherent associated functions.

[leoyvens]

Consider the code below:

enum Foo { Bar(i32) }

impl Foo {
    fn Bar(x: i32) -> Foo { 
        println!("I'm uncallable"); 
        Foo::Bar(x) 
    }
}

fn main() {
    Foo::Bar(0); // Variant constructor.
   <Foo>::Bar(0); // Inherent function.
}

It compiles successfully and terminates with no output. There is an ambiguity between the variant and the associated function, though it seems we always prefer the variant, making the associated function uncallable. Having an inherent associated function with the same name as a variant should be an error.

Edit: @petrochenkov points out that it's not actually uncallable, you can call it with <Foo>::Bar(0). A deny-by-default lint then perhaps?

[leonardo-m]

I agree this a breaking change worth having.

It compiles successfully

It compiles, but it gives a clear warning and it's often a bad idea to ignore rustc warnings:

warning: method `Bar` should have a snake case name such as `bar`
 --> ...\test.rs:4:5
  |
4 | /     fn Bar(x: i32) -> Foo {
5 | |         println!("I'm uncallable");
6 | |         Foo::Bar(x)
7 | |     }
  | |_____^
  |
  = note: #[warn(non_snake_case)] on by default

[petrochenkov]

This is a duplicate of some old issue, the decision was to always prioritize variants over other associated items, thus breaking the currently working way to call the "uncallable" Bar - <Foo>::Bar.

[petrochenkov]

There was also a suggestion to make this an overlap error instead of leaving the associated fn Bar legal but uncallable.

[petrochenkov]

This issue is a part of #26264 / rust-lang/rfcs#2338 really.

[leoyvens]

#28320 is the closest I could find.

[estebank]

@petrochenkov should we lint on the shadowing at least? Should we add some way of referring to the method at all?

[petrochenkov]

Variants are inherent associated items now, so this should be reported as an overlap error, similarly to

struct S;
impl S { fn foo() {} }
impl S { fn foo() {} }

[Centril]

@petrochenkov It doesn't seem to generate an overlap error currently?

[petrochenkov]

No, the overlap error is not reported currently, someone needs to implement it.