> On Aug 24, 2016, at 11:38 AM, Douglas Gregor <dgre...@apple.com> wrote:
>
>>
>> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution
>> <swift-evolution@swift.org <mailto: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.
Agreed. Unfortunately, everything is NDA’d at the moment.
Also, the problem (not the solution) is so obvious to me that I guess I am
having trouble explaining it. I never expected to have to argue that namespace
collisions can cause problems… I thought everyone had had that experience
(especially coming from ObjC).
I am not tied to this proposal, so much as I wanted to start a discussion
exploring the possible solution space. The explicit interface idea is a solid
option. I like that you wouldn’t necessarily have to expose a protocol’s
members without qualification. I should also be able to effectively rename a
member by calling the unexposed protocol implementation from a method with my
desired name.
tl;dr: I would like people to provide options/syntax for solving this problem
(even if they are a bit wild), so that we can cherry pick the best stuff and
put together an elegant solution…
Thanks,
Jon
>
>> 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
