Given that the type will/must be defined, implicitly or explicitly, by the adopter of a protocol, what about "adopterType"?
Mike On Mon, Dec 21, 2015 at 11:33 AM, Chris Lattner <[email protected]> wrote: > > On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution < > [email protected]> wrote: > > On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution < > [email protected]> wrote: > > On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution < > [email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
