type items do not work with enums

type items don't work with enums.

#[derive(Debug)]
enum Foo {
    Bar,
    Baz,
}
type Loz = Foo;
fn main() {
    let y = Loz::Bar;
    println!("{:?}", y);
}

On the stable channel the following error occurs:

<anon>:8:13: 8:21 error: type `Foo` does not implement any method in scope named `Bar`
<anon>:8     let y = Loz::Bar;
                     ^~~~~~~~
error: aborting due to previous error
playpen: application terminated with error code 101```

type only creates a type alias - it does not change resolution. Maybe documentation should be improved through.

The error in nightly is better:

<anon>:7:13: 7:21 error: no associated item named `Bar` found for type `Foo` in the current scope
<anon>:7     let y = Loz::Bar;

enum constructors are not associated items.

It seems to me that it is entirely reasonable to expect this to work. It’s not just a matter of documentation.

@chris-morgan

@chris-morgan

Maybe. However, associated items work rather differently from resolve-items - e.g. use Trait::Item doesn't work, but is the correct way with enums.

/cc @rust-lang/lang, should this work, or should this give a better error?

I think it's a somewhat tough question. The "integration" of enum variants and other kinds of associated items is, well, there isn't any, though it sort of feels like it'd be nice if there was. I certainly think is expected behavior for the moment, and I think that any fix would require some careful thought to be sure.

Yeah, this is definitely not a minor fix. I'd leave as is. I guess we could document better. I would only like to see a better error message if it can be done without making name resolution more awful.

Similarly, associated types too can resolve constructing functions, but not enum variants: http://is.gd/pnn7sC

It'd be very convenient to be able to think about enum variants in the same way we think about type constructing functions.

Rollup merge of rust-lang#32083 - nodakai:reference-scoped-enum-alias…

Is this problem related?

struct VecA { x: u32, y: u32 }
impl VecA {
    fn new() -> Self {
        Self { x: 0, y: 0 } // OK
    }
}
struct VecB(u32, u32);
impl VecB {
    fn new() -> Self {
        Self(0, 0) // Error
    }
}
fn main() {}

Any progress on this yet?

@leonardo-m

@leonardo-m

That's even less likely to be fixed - it's a call to a constructor function, and Self isn't even present in the value namespace, so you can't be expected to do

struct S(u32);
impl S {
    fn foo(&self) -> Self {
        let make_self = Self;
        make_self(Self.0);  
    }
}

Another similarly-annoying case is in impls, as you can't do Self::Bar (Self behaves like a type-alias).

As a lowly Rust noob, +1 on this. It's entirely against the intuitive behaviour that you'd expect, given how structs work.

@nikomatsakis

Since an RFC has already been proposed, and #31179 implements this, it should be worth merging.
cc @nikomatsakis

@mitchmindtree

I just hit this thing, when I wanted an alias of generic enum with concrete type parameter, as @mitchmindtree demonstrated in his example. I'm pretty fluent in Rust, yet I thought "WTF?!" and was confused for few minutes, then tried minimal example on playpen and then found this issue.

So apparently, it's not just confusing but also wastes time. I now have to rewrite things...

This was implemented in #56225 and the tracking issue is #49683

Navigation Menu

Repository navigation

type items do not work with enums #26264

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

type items do not work with enums #26264

Description

Activity

arielb1 commented on Jun 13, 2015

arielb1 commented on Jun 14, 2015

chris-morgan commented on Aug 13, 2015

arielb1 commented on Aug 13, 2015

steveklabnik commented on Nov 5, 2015

nikomatsakis commented on Nov 5, 2015

nrc commented on Nov 5, 2015

codyps commented on Jan 12, 2016

22 remaining items

leonardo-m commented on Jul 7, 2017

alexreg commented on Jul 8, 2017

arielb1 commented on Jul 8, 2017

achan1989 commented on Mar 6, 2018

anirudhb commented on Apr 4, 2018

Kixunil commented on May 26, 2018

petrochenkov commented on Jan 14, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions