- Start Date: 2014-09-16
- RFC PR #: https://github.com/rust-lang/rfcs/pull/234
- Rust Issue #: https://github.com/rust-lang/rust/issues/17323
Summary
Make enum variants part of both the type and value namespaces.
Motivation
We might, post-1.0, want to allow using enum variants as types. This would be backwards incompatible, because if a module already has a value with the same name as the variant in scope, then there will be a name clash.
Detailed design
Enum variants would always be part of both the type and value namespaces. Variants would not, however, be usable as types - we might want to allow this later, but it is out of scope for this RFC.
Data
Occurrences of name clashes in the Rust repo:
-
Key
inrustrt::local_data
-
InAddr
innative::io::net
-
Ast
inregex::parse
-
Class
inregex::parse
-
Native
inregex::re
-
Dynamic
inregex::re
-
Zero
innum::bigint
-
String
interm::terminfo::parm
-
String
inserialize::json
-
List
inserialize::json
-
Object
inserialize::json
-
Argument
infmt_macros
-
Metadata
inrustc_llvm
-
ObjectFile
inrustc_llvm
-
‘ItemDecorator’ in
syntax::ext::base
-
‘ItemModifier’ in
syntax::ext::base
-
FunctionDebugContext
inrustc::middle::trans::debuginfo
-
AutoDerefRef
inrustc::middle::ty
-
MethodParam
inrustc::middle::typeck
-
MethodObject
inrustc::middle::typeck
That’s a total of 20 in the compiler and libraries.
Drawbacks
Prevents the common-ish idiom of having a struct with the same name as a variant and then having a value of that struct be the variant’s data.
Alternatives
Don’t do it. That would prevent us making changes to the typed-ness of enums in the future. If we accept this RFC, but at some point we decide we never want to do anything with enum variants and types, we could always roll back this change backwards compatibly.
Unresolved questions
N/A