UnitEnum definition about enum-comparison

[Crell]

Oh bat gizzards. That was written before ScalarEnum extended UnitEnum. We should unify the terminology one way or the other. What do we call non-scalar enums then if not unit enums? Or is unit enum still the correct term?

[TysonAndre]

AbstractEnum being extended by UnitEnum and ScalarEnum is another option, if support for more immutable data types such as Distance::Miles(10) are added (Enum was your original proposal; that conflicted with the token)

The is_enum() function could alternately be reintroduced?

#43 is related

[Crell]

Thinking on the Naming Things(tm) problem, there's two levels to consider.

The cases:

• Unit cases - no scalar.
• Scalar cases - scalar equivalent. May extend in the future to another enum?
• Tagged cases - with associated data.

The enum types:

• Unit Enum - Contains only unit cases.
• Scalar Enum - Contains only scalar cases.
• Tagged Enum - Contains only unit cases OR tagged cases.

cases() makes sense on Unit Enum and Scalar Enum, but not on Tagged Enum, because tagged cases cannot be enumerated. So... whatever interfaces Tagged Enum ends up with cannot include cases().

Since scalar cases MAY extend in the future to non-scalars (although I don't quite grok that), maybe "Backed Enum"?

Breaking it up into tiny little bits:

interface NamedEnum {
  public string $name;
}

interface EnumerableEnum {
  public function cases();
}

interface BackedEnum {
  public string $value;
  public function from();
  public function tryFrom();
}

// Today Unit Enum, can still use that name.
class Suit implements NamedEnum, EnumerableEnum {}

// Today Scalar Enum.  We could call it Backed Enum, I guess?
class Size implements NamedEnum, EnumerableEnum, BackedEnum {}

// Future tagged cases
class Maybe implements NamedEnum {}

Thoughts?

[iluuu1994]

Hm, I think our current terminology is mostly fine, except for ScalarEnum. BackedEnum is fine by me although I'd still prefer ValueEnum. If we call ADTs ADTs or tagged unions there should be no confusion. I don't think we actually need a NamedEnum interface or an interface for ADTs (they have no special methods).

[Crell]

Well, one thing that the above breakdown demonstrated to me is that perhaps the ScalarEnum interface should not extend UnitEnum. Or rather, UnitEnum isn't a thing; An enum is enumerable or not. cases() won't appear on ADTs/tagged enums. NamedEnum doesn't need to be a thing because there's no methods on it, but I think EnumerableEnum and BackedEnum/ValueEnum/whatever make more sense, especially when looking forward to Tagged Enums.

[iluuu1994]

Coming back to the original issue: How about changing the sentence to something like:

An enum that has a finite set of values enum is known as a “Unit Enum”. All of the enums proposed in this RFC are Unit Enums but this would change if algebraic data types are accepted into the language.