[swift-evolution] Renaming for Protocol Conformance

[Jonathan Hull]

> On Aug 24, 2016, at 11:38 AM, Douglas Gregor <dgregor at apple.com> wrote:
> 
>> 
>> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto: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.  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160824/215b22c8/attachment.html>