> On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> 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. > > I think reusing "required" here (where "typealias" has already been reused) > could make the concept of associated types more opaque to new users.
I agree. There are a couple of potentially confusing issues here: - In principle, all of the declarations in the protocol are “requirements” that a type needs to fulfill to conform to the protocol. - Except for optional requirements in @objc protocols. - Except for requirements with default implementations (which currently cannot be written inline in the protocol, but should be allowed some day). Today’s typealiases can have "default implementations” as well. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
