Combine interfaces with + or &

[josh11b]

This isn't urgent, but came up during the meeting today.

Given two interfaces or type-types, say Printable and Launchable, we want an operator that forms the combination that has the union of the requirements and the types satisfying the result is the intersection of the types satisfying Printable and Launchable. There are two choices that are currently under consideration.

Plus Printable + Launchable:

• Matches Rust
• The type-type combination operation is commutative and associative, like +.
• Concern that we will have "sum types" and this will be a + operation applied to something frequently in the type position, but whose semantics are very different from the sum operation on types which has more of an "or" flavor (sum types commonly formed using | in other languages such as Haskell and ML).
• Context: Whether + is appropriate may depend on the answer to Is concatenation going to be written + or something else? #457 re: the operation for string concatenation.

Ampersand Printable & Launchable:

• Matches Swift
• Reads naturally as "and"
• & is more suggestive of intersection semantics (though this depends on whether your focus is on the requirements or the satisfying types)
• Concern that we will probably use prefix & for the "address of" operator and this is unrelated.

[jonmeow]

Perhaps TypeScript offers a precedent for & and | in a language that has both of these concepts? Typescript offers Union Types with | and Intersection Types with &. I believe Haskell's sum types are similar to TypeScript's union types, and what you're proposing here are similar to intersection types.

[zygoloid]

I find that I prefer using & for this. While the operation we're performing here is in some sense additive -- it's concatenating the witness tables of the two interfaces -- it doesn't feel enough like an addition to me. I'm also a little concerned about how this might fit into our story for an overloadable + operator in the future, and with foundational problems if that story involves a constraint that combines two interfaces. This operation seems like something primitive and non-user-extensible, so perhaps shouldn't be using an overloadable operator.

I also think there's a possibility we might want to support a corresponding | operation at some point (eg, I can support key types that are Hashable | Comparable) and & seems to play into that more elegantly.

[chandlerc]

I think this has consensus on &.