[swift-evolution] Renaming for Protocol Conformance

[Xiaodi Wu]

On Mon, Aug 22, 2016 at 11:59 PM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi everyone,
>
> We talked about this before when we were discussing mixins, and there
> seemed to be generally positive feelings towards it as a feature for the
> future.


It's been some time now since the original discussion, so perhaps you could
refresh our collective memory (or at least, mine): although it *seems* like
this feature might be useful, I can't recall a concrete use case where I've
felt like I needed this feature--do you have some examples?


>   I am fairly certain this affects the ABI though, so I thought I would
> bring it up now.
>
> If two protocols have methods/properties with the same name, but different
> signatures, we need a way to distinguish between them when attempting to
> conform to both.
>
>         protocol A {
>                 var x:Int {get set}
>         }
>
>         protocol B {
>                 var x:Double {get set}
>         }
>

Methods can be overloaded that differ in arguments or return type, so it
seems like this problem mainly exists with *properties* that differ in
type--am I wrong?


> One possibility is to allow a struct/class/enum to conform to the protocol
> while renaming one (or both) of the clashing methods:
>
>         struct C: A,B {
>                 var x:Int
>                 var y:Double implements B.x
>         }
>
> The conforming method/property would still have to have the same
> signature, but could have a different name (and parameter labels).  It
> would also allow protocol methods which have identical signatures and
> semantics, but different names to be implemented using the same method (i.e
> ‘implements D.z & E.w’).
>
> When something is cast to the protocol (say ‘as B’), then calling the
> property (e.g. ‘x’) would end up calling the implementation of the renamed
> property ( ‘y’ in this example) on the conforming type.
>

Reflecting on this proposed change, it occurs to me that something of value
would be lost, and I think that this something is actually rather valuable:

Today, when I see that a type conforms to (for example) Sequence, I know
that certain methods and/or properties exist on that type. Protocol
conformance guarantees a certain API, not just certain semantics.

Perhaps one way to mitigate this loss would be to have any renamed members
listed *in the declaration of conformance*, something like this (with some
additional bikeshedding):

```
struct MyGreatType : Sequence (count => length) {
  // MyGreatType conforms to Sequence but renames `count` to `length`
}
```

I think we would also want a way to retroactively conform using existing
> properties/methods in an extension declaring conformance.  Not sure what
> the best syntax for that would be.  Off the top of my head (though I would
> love to have something with less cruft):
>
>         extension D:B {
>                 @conform(to: B.x, with: D.y)
>         }
>
> or maybe just:
>
>         extension D:B {
>                 D.y implements B.x
>         }
>

If renamed members are declared along with protocol conformance, then the
syntax for retroactive modeling follows naturally:

```
extension D : B (x => y) { }
// again, the actual notation here is ugly
// but the underlying idea, I think, is worth considering
```

All of this is merely to start the discussion, so feel free to propose
> better syntax or a more elegant solution...
>
> Thoughts?
>
> Thanks,
> Jon
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160823/076d8ed2/attachment.html>