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

[Michael Henson]

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 <clattner at apple.com> wrote:

>
> On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/17cbc048/attachment.html>