Enum Named 'Type' in Nested Class Fails

Enum named `Type` in nested class fails

B.Type refers to class B's metatype, which is why the compiler doesn't like you defining an inner-enum with the name 'Type'.

You can use Type in variable/constant declaration to do class reflection:

class A {

    required init() {}
}

class B {
    var a: A.Type
    var aInstance: A

    init() {
        a = A.self
        aInstance = a()
    }
}

Enum named `Type` in nested class fails

B.Type refers to class B's metatype, which is why the compiler doesn't like you defining an inner-enum with the name 'Type'.

You can use Type in variable/constant declaration to do class reflection:

class A {

    required init() {}
}

class B {
    var a: A.Type
    var aInstance: A

    init() {
        a = A.self
        aInstance = a()
    }
}

Why can't I create an enum in an inner class in Java?

enum types that are defined as nested types are always implicitly static (see JLS §8.9. Enums)

You can't have a static nested type inside a non-static one (a.k.a an "inner class", see JLS §8.1.3. Inner Classes and Enclosing Instances).

Therefore you can't have an enum inner type inside a non-static nested type.

Which to prefer? An enum class, or a nested unnamed enum type?

Color3 and Color4 are both strong typing

No. Try this:

int x = Color3::red; // ok
int y = Color4::red; // error: cannot convert from 'Color4' to 'int'

The legacy enum is implicitly convertible to an integer, but enum class is it's own type.

As to which to prefer, refer to Why is enum class preferred over plain enum?

Nested Enum and Property Naming Conflicts

It would also be nice to know why this is disallowed. Maybe Eric Lippert or someone could chime in on the decision to forbid it?

The point of the rule is to ensure that there is no ambiguity within the class when looking up a name. Certain regions of code are designated as defining a 'declaration space'. The fundamental rule of declaration spaces is no two things declared in the same declaration space have the same name (except for methods, which must differ by signature, not name.)

Making exceptions to this rule just makes things more confusing, not less confusing. I agree that it is vexing that you cannot have a property and an enum of the same name declared in the same declaration space, but once you start making exceptions then it just gets to be a mess. It's usually a nice property that a name uniquely identifies a method group, type parameter, property, and so on.

Note that this rule applies to things declared in a declaration space, not things used in a declaration space. It is perfectly legal to say "public Suit Suit { get; set; }" provided that the type Suit is not declared in the same declaration space as the property. When someone says "Suit.X", figuring out whether X is on the type (that is, X is a static member) or the property (that is, X is an instance member) is a bit tricky. See my article on how we do that for details:

http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx

---

Related Topics