Keyword idea: Boosting enum functionality

language design
19

So I've brooding over this a bit now.
Essentially there are 3.5 cases where you want to make sure you aren't forgetting any enum variant.


Case one:
Decide to do something based on the enum variant.
That's covered by your trusty old match function.
So we're good here.

Case two:
Make sure you return every variant based on a input.
E.g. useful for the mentioned from_string function.

Case three:
Do something for every enum variant.
Not necessarily with the enum variant itself but the variant is reason why this code exists.
This functionality would be an absolute boon for writing tests.
This is tricky since @mjbshaw concerns that mishaps are still to easy is true,
at least with the current approach.


So I made a revision to my initial suggestion:

//Case two:
let variant =  match input as Enum {
                  _ => Enum::Variant, //to intentionally ignore a Variant needs to be after the catch all.
                  /*normal match flow
                  but compiler makes
                  sure every variant
                  is returned at least
                  once.
                  Throw a warning
                  by returning a variant
                  more than once.*/
               }

//Case three:
      do for Enum{
          Enum::Variant(field type) escaped before { block },
         {Enum::Variant(filled field) used inside block},
          Enum::Variant _, //case ignored
          /*Same spiel as before, make sure every
          variant is mentioned at least once.
          Throw an error or warning otherwise.*/
      }

I think this should add a considerable amount of value to Rusts functionality and make everyone happy.
It also avoids a new keyword by using existing/reserved ones while simultaneously being more concise.

What ya´ think?

Oh, and the Case 0.5 would be to include a std. macro enum iterator :wink:



@idanarye
I fail to see value in your suggestion,because the fields would be ignored anyway.
The primary goal is just to show there is something, so you're aware of it.
Actually, putting in the correct default/dummy data could make sure the compiler yells at you if the field-type changes.
So yeah good call, if that was your intention.