> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
