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