> On 23 Aug 2016, at 07:39, Karl <[email protected]> wrote: > > >> On 23 Aug 2016, at 06:59, 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 > > What about if we synthesised members on the conforming type? So I’m thinking > > protocol MyProtoOne { > func doSomething() > } > > protocol MyProtoTwo { > func doSomething() > } > > struct ImplementsOne : MyProtoOne { > func doSomething() { > // Unambiguous. Satisfies MyProtoOne. > } > } > > struct ImplementsBoth : MyProtoOne, MyProtoTwo { > > func MyProtoOne.doSomething() { > // Or some other declaration modifier to say this for MyProtoOne > } > > func MyProtoTwo.doSomething() { > // ... > } > } > > ImplementsOne().doSomething() // unambiguous intention at call-site > ImplementsBoth().MyProtoOne.doSomething() // intention at call-site must be > explicit. What kind of thing do you want to look at ImplementsBoth() as? > ImplementsBoth().MyProtoTwo.doSomething() > > I think this would be relatively simple to implement. We just disambiguate at > declaration site, and the synthesised members > ImplementsBoth().MyProto{One/Two} are the protocol-witness tables to > disambiguate at the call-site. >
> The thing is that we would need to mangle those names differently, and for > ABI resilience (the ability to add a protocol with a conflicting name later) > that would mean also mangling the protocol name in to the non-conflicting > cases (ImplementsOne.MyProtoOne.doSomething). That means if you had > ImplementsOne.doSomething in v1 and added the MyProtoOne protocol in v1.1, > you would need to add a plain doSomething() method which doesn’t belong to a > protocol. > > That’s the thing — members would kind of “belong” to the protocol conformance > on the type, rather than being plain top-level members on the type itself > (although as long as there are no conflicts, you could use them as such and > the compiler would know which members you mean). That may be beneficial for > mixins. > > Karl > Actually, reading the next thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160822/026524.html This could even be a feature. Karl _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
