[swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

Brent Royal-Gordon brent at architechies.com
Sat Dec 19 19:09:20 CST 2015

> There is another alternative. Rather than trying to come up with another brand-new keyword, we can re-use one that has an existing and appropriate meaning: required.
> Example:
> protocol ExampleProtocol {
>   required typealias Element
>   typealias MethodSignature = (arg: Element) -> Bool
>   ... etc
> }
> It's a little more verbose at the point of use but the declarations are relatively uncommon and this usage is clearly separate from regular typealias declarations.

I don't think `required` captures the intended meaning *at all*. You're not required to declare the type of a "required typealias"—it's often, perhaps even usually, inferred. On the other hand, all types conforming to ExampleProtocol are "required" in some sense to have an Element, but they're also "required" to have a MethodSignature. (In fact, they're required to have exactly the MethodSignature specified there, but they can have any Element they want.) It's just not a good match.

If you wanted to analogize associated types to some existing feature, it would clearly be generics (but this is not done for very good reasons). If you wanted to reuse an existing keyword at all costs, I suspect what you should actually do is mark the non-associated type with `final` (but this doesn't match typealiases in other types, and it doesn't solve the searchability problem with using "typealias" for associated types).

The whole reason we got into this mess is because we unwisely reused a keyword for something barely related. Let's not do it again.

Brent Royal-Gordon

More information about the swift-evolution mailing list