Since this is breaking everything anyway, how about syntax to let the
match run inside the enum namespace? e.g.
enum Color { Red, Green, Blue }
fn main() {
let x = Color::Red;
match Color::{x} {
Red => ...
Green => ...
Blue => ...
}
}
Or even infer that x is of type Color and let the compiler
transparently allow omitting the prefix within the match.
That would remove the primary source of "noisy boilerplate".
martin
On Fri, Mar 22, 2013 at 4:51 PM, Patrick Walton <[email protected]> wrote:
> Hi everyone,
>
> It's been proposed that we place enum variants under the enum itself. That
> is:
>
> enum Option<T> {
> None,
> Some<T>,
> }
>
> Would be accessed as:
>
> fn main() {
> let x = Option::None;
> }
>
> The advantages of this are:
>
> * Rust programmers very frequently generate ad-hoc prefixes to group
> variants under their namespaces. Prefixes seem to me to be the sincerest
> form of feature request for namespaces. (See Objective-C or Gecko `NSFoo`,
> GLib `g_`, etc.)
>
> * You can get the old behavior with `use` or `pub use`.
>
> * Other modules can import all variants belonging to an enum by simply
> writing (say) `use option::Option::*;`. This is a common thing to want and
> would, for example, eliminate all the `use obsolete::{ObsoleteFoo,
> ObsoleteBar, ...}` cruft in `parser.rs`. Note that Haskell introduced
> special notation for this into their `import` statements.
>
> * C++11 went the direction of enum variant namespacing with `enum class`. I
> worry we may be making the same mistake that led them to introduce two
> incompatible versions of enums.
>
> * This may clean up the `use core::option::Option` stuttering in the
> `option` module (and in a few related cases, like `std::list::List`).
> Instead of having types like `std::option::Option`, variants like
> `std::option::None`, and methods like `std::option::Option::is_none`, we
> could have simply `std::Option`, `std::Option::None`, and
> `std::Option::is_none` respectively. This seems to read nicer.
>
> The disadvantages are:
>
> * `::` will show up for many casual uses of enums. e.g.
>
> enum Color { Red, Green, Blue }
> fn main() {
> let x = Color::Red;
> match x {
> Color::Red => ...
> Color::Green => ...
> Color::Blue => ...
> }
> }
>
> Thoughts? This would be a very late-stage change that will break pretty much
> all Rust code in existence, and it has disadvantages, but the advantages
> seem compelling enough to consider it...
>
> Patrick
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
