Associated types with the same name as a function make an unimplementable trait

[talchas]

trait Foo {
    type bar;
    fn bar();
}

is accepted (though generally considered bad style), but is unimplementable:

impl Foo for () {
    type bar = ();
    fn bar() {
    }
}

gives the error "item bar is an associated method, which doesn't match its trait <() as Foo>"

This seems kinda silly. Allowing this non-conflicting name reuse might be useful for macros as long as procedural macros don't yet exist and concat_idents is useless. Forbidding it outright seems fine, but should be done at the trait definition.

[durka]

I think it should be forbidden. How would you ever refer to the type and function?

[talchas]

In type context Foo::bar is the type, in expression context Foo::bar is the function, same as other cases like type foo = i32; fn foo() {}.

[KalitaAlexey]

@talchas What did you need that for? I don't see any reason to make it work.

[talchas]

Someone in #rust wanted the ability to generate an associated type for fn names in a macro that generates that trait, ala impl Trait (the fn would then return that associated type, and there would be some trait bound on the type). Given the lack of any usable concat_idents, this came up as an ugly but potentially workable way to have those names, except for this.

[durka]

Huh, I guess if it's not ambiguous for normal types then this should be
allowed for consistency (and dastardly macro hijinks).

On Aug 12, 2016 01:18, "talchas" notifications@github.com wrote:

Someone in #rust wanted the ability to generate an associated type for fn
names in a macro that generates that trait, ala impl Trait (the fn would
then return that associated type, and there would be some trait bound on
the type). Given the lack of any usable concat_idents, this came up as an
ugly but potentially workable way to have those names, except for this.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#35600 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3nykZ8sxI4cj3vW5-MdaxtrtVUWOvks5qfAIYgaJpZM4JieLk
.

[ollie27]

It would make sense if this was allowed but it seems really buggy right now. For example the following works (playpen):

pub trait Foo {
    type bar;
    fn bar(&self) {}
}
impl Foo for char {
    type bar = u8;
}
fn main() {
    Foo::bar(&'a');
    let _: <char as Foo>::bar = <char as Foo>::bar::max_value();
}

However this fails even though all that's different is the order of items in the trait definition which I thought shouldn't matter (playpen):

pub trait Foo {
    fn bar(&self) {}
    type bar;
}
impl Foo for char {
    type bar = u8;
}
fn main() {}

Also this fails (playpen):

pub trait Foo {
    type bar;
    fn bar(&self) {}
}
impl Foo for char {
    type bar = u8;
}
fn main() {
    'a'.bar();
}

Giving this nonsense error message:

error: no method named `bar` found for type `char` in the current scope
 --> <anon>:9:9
  |
9 |     'a'.bar();
  |         ^^^
  |
  = note: found the following associated functions; to be used as methods, functions must have a `self` parameter
note: candidate #1 is defined in the trait `Foo`
 --> <anon>:2:5
  |
2 |     type bar;
  |     ^^^^^^^^^
  = help: items from traits can only be used if the trait is implemented and in scope; the following trait defines an item `bar`, perhaps you need to implement it:
  = help: candidate #1: `Foo`

[apasel422]

CC #27048.