I was just thinking about proposing something like this.

+1.

Charles

> On Aug 22, 2016, at 11:59 PM, Jonathan Hull via swift-evolution 
> <[email protected]> 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}
>       }
> 
> 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.
> 
> 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...
> 
> Thoughts?
> 
> Thanks,
> Jon
> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to