> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution
> <swift-evolution@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. 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}
> }
I believe that this can happen, and it is unfortunate that Swift has no
mechanism for dealing with it today. However, I agree with Xiaodi that your
proposal would be much stronger with real-world examples rather than
theoretical ones.
> 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.
Sure. Calling through the protocol type will get whatever method/property
satisfied the protocol requirement. Yes, there are limits here due to protocols
with associated types and Self requirements, but I fully expect those to go
away at some point with generalized existentials.
> 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
> }
>
>
> All of this is merely to start the discussion, so feel free to propose better
> syntax or a more elegant solution...
C# has a much narrower solution that lets you qualify the method declaration
(rather than doing a full rename), e.g.,
struct C : A {
var x: Int
var y: Double
}
extension C : B {
var B.x: Double {
get { return y }
set { y = newValue }
}
}
They have some examples at:
https://msdn.microsoft.com/en-us/library/aa288461(v=vs.71).aspx
<https://msdn.microsoft.com/en-us/library/aa288461(v=vs.71).aspx>
One would have to figure out what the name-lookup rules are, of course, but
this might allow us to solve the problem without introducing a generalized
renaming mechanism.
- Doug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
