rfc:enumerations_and_adts

This is an old revision of the document!


PHP RFC: Enumerations and Algebraic Data Types

  • Version: 0.9
  • Date: 2020-09-19
  • Author: Larry Garfield (larry@garfieldtech.com), Ilija Tovilo (tovilo.ilija@gmail.com)
  • Status: Draft

Introduction

This RFC introduces Enumerations to PHP. Specifically, it introduces what are variously called “Algebraic Data Types”, “tagged unions”, or simply “enumerations” depending on the language. This capability offers greatly expanded support for data modeling, custom type definitions, and monad-style behavior.

Many languages have support for enumerations of some variety. A survey we conducted of various languages found that they could be categorized into three general groups: Fancy Constants, Fancy Objects, and full Algebraic Data Types. For this implementation we opted to implement full Algebraic Data Types, as that offers the most robust set of functionality while also degrading gracefully to simpler use cases. (Or it progressively enhances to more complex use cases, depending on your point of view.)

The specific implementation here draws inspiration primarily from Swift, Rust, and Kotlin, but is not (nor is it intended as) a perfect 1:1 port of any of them.

Proposal

Basic enumerations

This RFC introduces a new language construct, enum. Enums are similar to classes, and share the same namespaces as classes, interfaces, and traits. They are also autoloadable the same way. An Enum defines a new type, which has a fixed, limited number of possible legal values.

enum Suit {
  case Hearts;
  case Diamonds;
  case Clubs;
  case Spades;
}

This declaration creates a new enumerated type named Suit, which has four and only four legal values: Suit::Hearts, Suit::Diamonds, Suit::Clubs, and Suit::Spades. Variables may be assigned to one of those legal values. A function may be type checked against an enumerated type, in which case only values of that type may be passed.

$val = Suit::Diamonds;
 
function pick_a_card(Suit $suit) { ... }
 
pick_a_card($val);       // OK
pick_a_card(Suit:Clubs); // OK
pick_a_card('Spades');   // throws TypeError

In the simple case, multiple cases may be defined on a single line. The following is semantically equivalent to the definition above.

enum Suit {
  case Hearts, Diamonds, Clubs, Spades;
}

An Enumeration may have one or more case definitions, with no maximum, although at least one is required.

Cases are not backed by a primitive value. That is, Suit::Hearts is not equal to 0. Instead, each case is backed by a singleton object of that name. That means that:

$a = Suit::Spades;
$b = Suit::Spades;
 
$a === $b; // true

Each Case class includes a default __toString() implementation that returns the name of the Case as a string, without the Enum type. That is:

print Suit::Clubs; 
// prints "Clubs", not "Suit::Clubs".

That function may be overridden if desired. (See below.)

Enumerated Case Methods

Backward Incompatible Changes

“enum” becomes a language keyword, with the usual potential for naming conflicts with existing global constants.

Proposed PHP Version(s)

Next PHP 8.x.

RFC Impact

Open Issues

Make sure there are no open issues when the vote starts!

Unaffected PHP Functionality

List existing areas/features of PHP that will not be changed by the RFC.

This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.

Future Scope

This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.

Proposed Voting Choices

This is a simple yes/no vote to include Enumerations. 2/3 required to pass.

Patches and Tests

Links to any external patches and tests go here.

If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.

Make it clear if the patch is intended to be the final patch, or is just a prototype.

For changes affecting the core language, you should also provide a patch for the language specification.

Implementation

After the project is implemented, this section should contain

  1. the version(s) it was merged into
  2. a link to the git commit(s)
  3. a link to the PHP manual entry for the feature
  4. a link to the language specification section (if any)

References

Links to external references, discussions or RFCs

Rejected Features

Keep this updated with features that were discussed on the mail lists.

rfc/enumerations_and_adts.1600533298.txt.gz · Last modified: 2020/09/19 16:34 by crell