Intersection type

The above minimalist example can be realized using inheritance, for instance by deriving the classes Chicken and Cow from a base class Animal. However, in a larger setting, this could be disadvantageous. Introducing new classes into a class hierarchy is not necessarily justified for cross-cutting concerns, or maybe outright impossible, for example when using an external library. Imaginably, the above example could be extended with the following classes:

• a class Horse that does not have a produce method;
• a class Sheep that has a produce method returning Wool;
• a class Pig that has a produce method, which can be used only once, returning Meat.

This may require additional classes (or interfaces) specifying whether a produce method is available, whether the produce method returns food, and whether the produce method can be used repeatedly. Overall, this may pollute the class hierarchy.

The above minimalist example already shows that duck typing is less suited to realize the given scenario. While the class RandomNumberGenerator contains a produce method, the object randomNumberGenerator should not be a valid argument for animalToFood. The above example can be realized using duck typing, for instance by introducing a new field argumentForAnimalToFood to the classes Chicken and Cow signifying that objects of corresponding type are valid arguments for animalToFood. However, this would not only increase the size of the respective classes (especially with the introduction of more methods similar to animalToFood), but is also a non-local approach with respect to animalToFood.

The above example can be realized using function overloading, for instance by implementing two methods animalToFood(animal: Chicken): Egg and animalToFood(animal: Cow): Milk. In TypeScript, such a solution is almost identical to the provided example. Other programming languages, such as Java, require distinct implementations of the overloaded method. This may lead to either code duplication or boilerplate code.

The above example can be realized using the visitor pattern. It would require each animal class to implement an accept method accepting an object implementing the interface AnimalVisitor (adding non-local boilerplate code). The function animalToFood would be realized as the visit method of an implementation of AnimalVisitor. Unfortunately, the connection between the input type (Chicken or Cow) and the result type (Egg or Milk) would be difficult to represent.

On the one hand, intersection types can be used to locally annotate different types to a function without introducing new classes (or interfaces) to the class hierarchy. On the other hand, this approach requires all possible argument types and result types to be specified explicitly. If the behavior of a function can be specified precisely by either a unified interface, parametric polymorphism, or duck typing, then the verbose nature of intersection types is unfavorable. Therefore, intersection types should be considered complementary to existing specification methods.

Scala supports type declarations [7] as object members. This allows a type of an object member to depend on the value of another member, which is called a path-dependent type.[8] For example, the following program text defines a Scala trait Witness, which can be used to implement the singleton pattern.[9]

trait Witness {
  type T
  val value: T {}
}

The above trait Witness declares the member T, which can be assigned a type as its value, and the member value, which can be assigned a value of type T. The following programm text defines an object booleanWitness as instance of the above trait Witness. The object booleanWitness defines the type T as Boolean and the value value as true. For example, executing System.out.println(booleanWitness.value) prints true on the console.

object booleanWitness extends Witness {
  type T = Boolean
  val value = true
}

Let ${\displaystyle \langle {\textsf {x}}:\sigma \rangle }$ be the type (specifically, a record type) of objects having the member ${\displaystyle {\textsf {x}}}$ of type ${\displaystyle \sigma }$. In the above example, the object booleanWitness can be assigned the dependent intersection type ${\displaystyle (x:\langle {\textsf {T}}:{\text{Type}}\rangle )\cap \langle {\textsf {value}}:x.{\textsf {T}}\rangle }$. The reasoning is as follows. The object booleanWitness has the member T that is assigned the type Boolean as its value. Since Boolean is a type, the object booleanWitness has the type ${\displaystyle \langle {\textsf {T}}:{\text{Type}}\rangle }$. Additionally, the object booleanWitness has the member value that is assigned the value true of type Boolean. Since the value of booleanWitness.T is Boolean, the object booleanWitness has the type ${\displaystyle \langle {\textsf {value}}:{\textsf {booleanWitness.T}}\rangle }$. Overall, the object booleanWitness has the intersection type ${\displaystyle \langle {\textsf {T}}:{\text{Type}}\rangle \cap \langle {\textsf {value}}:{\textsf {booleanWitness.T}}\rangle }$. Therefore, presenting self-reference as dependency, the object booleanWitness has the dependent intersection type ${\displaystyle (x:\langle {\textsf {T}}:{\text{Type}}\rangle )\cap \langle {\textsf {value}}:x.{\textsf {T}}\rangle }$.

Alternatively, the above minimalistic example can be described using dependent record types.[10] In comparison to dependent intersection types, dependent record types constitute a strictly more specialized type theoretic concept.[6]