[swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

Chris Lattner clattner at nondot.org
Wed Jul 5 12:53:45 CDT 2017

> On Jun 27, 2017, at 2:26 PM, David Moore via swift-evolution <swift-evolution at swift.org> wrote:
> Onto Option #2, the idea of using base types to express more explicit definitions to solve the initial problem. When it comes to using a base type to correctly disambiguate these types of situations, it may be familiar to some who like a more concrete implementation, although it eliminates possible convenience, but still requires knowledge. Options #2 would look something like the following.
> protocol Foo {
>  associatedtype ABC
> }
> struct Bar<ABC>: Foo {
>  typealias Foo.ABC = Bar.ABC // Quite explicit and communicates the solution clearly.
> }
> Options #2, as you can see above, would also be source compatible because it would not impose on already defined typealias’ or other implementations. This could be an opt-in feature. However, I don’t know if it is as nice as just pure inference, which doesn’t seem too much more difficult than this would be, but I’m not sure about that.

Something like this seems like the right approach to me.  Swift’s underlying implementation model (for non- at objc protocols) does not require exact name matches and uniqueness.  This means that (from an implementation perspective) it would be possible to allow “remapping” of requirements to implementations, even if they have different (or conflicting) names.

This can be useful in some cases, like the one you give above.  That said, it would be a power user feature only necessary in specific situations, and thus it makes sense to have super explicit syntax.  Given that remapping can apply to any requirement (be it a type, method, property, subscript, …) it may make sense to make it an explicit decl modifier like:

  protocol P {
    var x : Int
    func f() -> Int

  struct S : P {
    var y : Int
    remapped var P.x = y

    func g() -> Int { return 42 }
    remapped var P.f = g

or something.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170705/06463d38/attachment.html>

More information about the swift-evolution mailing list