Tweaks

Author: sfackler

active/0000-enum-namespacing.md

@@ -169,13 +169,14 @@ which contains 232 variants. It would be ridiculous to `pub use` all of them!
 With namespaced enums, this kind of reexport becomes a simple `pub use` of the
 enum itself.
 
-Sometimes a developer wants to use many of an enum's variants, and doesn't want
-to require the use of the parent module (in flat enums) or the enum (in
-namespaced enums) as part of the name. This is especially common for private,
-internal enums within a crate. With flat enums, this requires each enum to be
-`use`d individually, which can get *extremely* verbose. For example, take
-[this](https://github.com/sfackler/rust-postgres/blob/557a159a8a4a8e33333b06ad2722b1322e95566c/src/lib.rs#L97-L136)
-from `rust-postgres`:
+Sometimes a developer wants to use many variants of an enum in an "unqualified"
+manner, without qualification by the containing module (with flat enums) or
+enum (with namespaced enums). This is especially common for private, internal
+enums within a crate. With flat enums, this is trivial within the module in
+which the enum is defined, but very painful anywhere else, as it requires each
+variant to be `use`d individually, which can get *extremely* verbose. For
+example, take this [from
+`rust-postgres`](https://github.com/sfackler/rust-postgres/blob/557a159a8a4a8e33333b06ad2722b1322e95566c/src/lib.rs#L97-L136):
 ```rust
 use message::{AuthenticationCleartextPassword,
               AuthenticationGSS,
@@ -331,7 +332,7 @@ struct Bar;
 
 fn broken(f: Foo) {
     match f {
-        Bar => {} // ~ ERROR expected a `Foo` but found struct `Bar`
+        Bar => {} // ~ ERROR expected a `Foo` but found type `Bar`
         Baz => {}
     }
 }
@@ -381,10 +382,12 @@ increased complexity comes an increased chance of bugs.
 # Alternatives
 
 We can push to switch entirely to namespaced enums before 1.0. This will allow
-us to avoid the compatibility fallback, at the cost of adding a significant
-amount of work to the 1.0 docket. Given that there is a reasonable post-1.0
-path forward, the pain required to push it through before 1.0 does not seem
-worth it.
+us to avoid the compatibility fallback and minimize library cruft, at the cost
+of adding a significant amount of work to the 1.0 docket. If we decide to go
+down this route, we could use the same implementation strategy laid out here to
+avoid breaking the entire world at once - implement the fallback and lint at a
+default (or forced) `warn` level and then remove both after some period of
+time.
 
 Earlier iterations of namespaced enum proposals suggested preserving flat enums
 and adding `enum mod` syntax for namespaced enums. However, variant namespacing