[Pitch] Introduce existential `any`

Evolution Pitches
84

Hi @hborla, it's great to see that you're working on this problem. Of course it is my duty to trot out, briefly, the points I always | bring | up on this topic:

  • We will someday need to represent things like “any Collection whose Element is Int.” The natural way to spell it in Swift is something like “Collection where Element == Int” (I know there's been talk out there about Collection<.Element == Int> but I honestly can't see how angle brackets improve on where).
  • The more constraints you add to an existential, the more of the protocol's declared API becomes available.
  • “any P” doesn't read like a thing that's only going to expose part of the API that every P in fact must expose, which has always been my worry about existentials. If every P is declared to have a foo property and I am handling something called “any P,” it's not obvious why it has no foo, any more than it's obvious why P has no foo today.
  • “P where _” ain't pretty, but it at least suggests that something is unknown, and you might need to add something.
  • We could add any to the front of these syntaxes, and I don't object to it if people like it… but it isn't adding anything essential once you have ”P where _.”

Phew, duty done :vulcan_salute:

Oh, whoa, I just noticed this:

What's that supposed to mean? IIUC any P is a concrete type in this proposal but you're not allowed to write

func test<T>(_: T) where T == Int // Int is a cocrete type

at least, IIRC.

-Dave

4 Likes