RFC: Enum trait

[ghost]

Since I've been doing some work with the deriving code in libsyntax, I thought I'd solicit opinions on adding a new trait to libcore:

trait Enum {
    static fn enumerate(blk: &fn(Self) -> bool);
}

Obviously, this would be most useful for enums with only nullary variants, but other enumerable types could take advantage of it as well (bool::all_values currently serves the same purpose).

This would make it possible to write

// enum Dir { North, East, South, West }
for Enum::enumerate |dir: Dir| { ... }

instead of

for [North, East, South, West].each |dir| { ... }

A standard implementation for enums with only nullary variants would be made available through #[deriving(Enum)], and a default method (or utility trait/impl until those are working) would be provided for obtaining all the values in a vector. It might be beneficial to have a static fn cardinality() -> Option<uint> method on the trait as well.

If the trait name is too easily confused with the keyword, another option is Enumerable.

[ghost]

Maybe it makes more sense to have a method on the trait that returns an iterator instead, to better support lazy operations and the usual extended iterator methods.

[kud1ing]

Haskell's Enum is similar but not quite: http://zvon.org/other/haskell/Outputprelude/Enum_c.html

[catamorphism]

I would prefer something more like Haskell's Enum type class, with fromEnum and toEnum methods. That seems more general to me -- I think you could implement what you're proposing in terms of it.

[ghost]

I think converting between enums and integers is a separate issue. This is just for those scenarios in which you need to access every variant of a C-like enum (or some other completely enumerable series, be it bitstrings, Fibonacci numbers, or the legal values of bool).

I'm proposing (in the static- and pure-less future) something like:

trait Enumerable<I: BaseIter<Self>> {
    fn enumerator() -> I;
}

which would be implemented like

enum Dir { North, East, South, West }

/* everything below this would be generated by `#[deriving(Enumerable)]` on the enum */

impl Enumerable<DirEnumerator> for Dir {
    fn enumerator() -> DirEnumerator { DirEnumerator }
}

struct DirEnumerator;

impl BaseIter<Dir> for DirEnumerator {
    fn each(&self, blk: &fn(&Dir) -> bool) {
        [North, East, South, West].each(blk);
    }

    fn size_hint(&self) -> Option<uint> { Some(4) }
 }

Then you might have some theoretical trait for C-like enums like

trait Enum<I: BaseIter<Self>> : Eq + Ord + TotalOrd
                              + Enumerable<I>
                              + FromInt + ToInt
                              + FromStr + ToStr { }

[z0w0]

@catamorphism thoughts on the clarification @apasel422 has provided? I certainly think what he has proposed would be incredibly useful (I've need that sort of thing before). Although, perhaps converting to/from integers could be provided on the same trait?

[catamorphism]

@z0w0 I don't have a strong opinion. In any case, I don't think it should be on the backwards-compatible milestone. Nominating for feature-complete so we can discuss.

[emberian]

@thestinger @huonw could this automatically be derived? I envision it just expanding to [A, B, C, D].iter() or somesuch..

[graydon]

I think this is just a deriving mode that produces an iterator, yeah. Not bad, but it should just be a feature (and I'm not even sure it's one that ought to block feature-complete). It's neat but I could live without it.

[graydon]

just a bug, removing milestone/nomination.

[huonw]

triage: no change. I think calling it Enum would be confusing.

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#284