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

Dave Abrahams dabrahams at apple.com
Sat Dec 19 22:14:03 CST 2015


> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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.

No, but it is required to exist and can't always be inferred.  It puts a constraint on the type that is declared to conform.  This is a requirement in exactly the same sense that other protocol requirements are requirements.  Notably operator requirements may be satisfied "implicitly" by declarations that already exist, but they are still requirements.

> 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.)

No, that is not a protocol requirement; it doesn't put a constraint on any type that is declared to conform.

> 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
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave





More information about the swift-evolution mailing list