lang (enum | resolve | sum-types)
Make enum variants part of both the type and value namespaces.
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.
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.
Occurrences of name clashes in the Rust repo:
Key in rustrt::local_data
InAddr in native::io::net
Ast in regex::parse
Class in regex::parse
Native in regex::re
Dynamic in regex::re
Zero in num::bigint
String in term::terminfo::parm
String in serialize::json
List in serialize::json
Object in serialize::json
Argument in fmt_macros
Metadata in rustc_llvm
ObjectFile in rustc_llvm
'ItemDecorator' in syntax::ext::base
'ItemModifier' in syntax::ext::base
FunctionDebugContext in rustc::middle::trans::debuginfo
AutoDerefRef in rustc::middle::ty
MethodParam in rustc::middle::typeck
MethodObject in rustc::middle::typeck
That's a total of 20 in the compiler and libraries.
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.
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.
N/A