[Pitch 2] Light-weight same-type requirement syntax

There is zero interest on the Core Team in reserving P<Int> for “generic protocols”. I can say that with confidence because we’ve had multiple conversations about it. To give you an idea of the tenor of those discussions, they’ve all turned into discussions about whether it’s acceptable Evolution procedure to just rule something out by fiat or if we formally need to go through the proposal process for a negative feature.

Arguments against using this syntax include:

  • There are other reasonable and available spellings for that concept if we decide we want it, such as (T,U) : Convertible. Thus we’re not talking about ruling the feature out completely; we’re talking about the practical consequences of using this particular spelling.
  • The generic spelling inappropriately elevates one parameter over the other when in fact there’s no relationship.
  • The second parameter would behave unlike an ordinary associated type, so it ought to be declared differently, and it certainly needs to be used differently. For example, since there is no functional dependency, Self has no unique member of that name. Using member syntax to declare the “associated type” would be misleading. Using member syntax to name it would immediately break down in any context where multiple conformances are known.
  • The generic spelling is familiar and widely used, and it would induce programmers to use the feature when in fact they ought to have a functional dependency, as they would with an ordinary protocol.

Additionally, aside from the syntax, there are fundamental soundness problems with the feature in terms of the type-level computation it accidentally enables. It’s roughly analogous to an automaton going from one stack to two. If memory serves, folks in the Haskell world were exploring the research potential and expressive power of lifting some of the restrictions on type class instances when suddenly they realized that everything they were doing was already enabled by multi-parameter type classes, just with less convenient syntax. So it’s not something we should do casually.

10 Likes