rfc:dnf_types

This is an old revision of the document!


PHP RFC: Disjunctive Normal Form Types

  • Version: 0.9
  • Date: 2021-11-04
  • Author: George Peter Banyard, girgias@php.net; Larry Garfield, crell@php.net
  • Status: Draft

Introduction

Disjunctive Normal Form (DNF) is a standard way of organizing boolean expressions. Specifically, it means structuring a boolean expression into an ORed series of ANDs. When applied to type declarations, it allows for a standard way to write combined Union and Intersection types that the parser can handle.

This RFC proposes to support DNF types in order to allow mixing of union and intersection types.

Proposal

Examples

For all examples that follow, assume the following definitions exist:

interface A {}
interface B {}
interface C extends A {}
interface D {}
 
class W implements A {}
class X implements B {}
class Y implements A, B {}
class Z extends Y implements C {}

DNF types would allow type declarations for properties, parameters, and return values in the following form:

// Accepts an object that implements both A and B, OR an object that implements D.
A&B|D

// Accepts an object that implements C, OR a child of X that also implements D, OR null.
C|X&D|null

// Accepts an object that implements all three of A, B, and D, OR an int, OR null.
A&B&D|int|null

The following examples are not in DNF form, and thus will generate a parse error. However, they can be rewritten to DNF as shown.

A&(B|D)
// Can be rewritten as A&B|A&D

A|(B&(D|W)|null)
// Can be rewritten as A|B&D|B&W|null

Requiring DNF for all type declarations allows conceptually all potential combinations of intersection and union rules, but in a standard fashion that is easier for the engine and easier for humans and static analyzers to comprehend.

Return variance

Backward Incompatible Changes

None.

Proposed PHP Version(s)

8.2

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

Non-DNF types

In theory, supporting conjunctive normal form type definitions (and ANDed list of ORs) may be possible. However, as DNF is able to represent all reasonable boolean expressions the authors have no intent to pursue this direction.

Type aliasing

DNF types have the potential to be rather verbose. That puts additional pressure on the language to develop a type aliasing mechanism to allow for more convenient type names. Such an RFC is best implemented as a separate follow up.

Proposed Voting Choices

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

Patches and Tests

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/dnf_types.1636038760.txt.gz · Last modified: 2021/11/04 15:12 by crell