[swift-evolution] Mark protocol methods with their protocol

[Jean-Denis Muys]

I watched this thread with a lot of attention, starting neutral. You must say that Karl won me over. His proposal would make Swift more expressive, and less error prone in cases of protocol conformance with name collisions. I am at this point +1

Jean-Denis

Sent from my iPhone

> On 22 Sep 2016, at 07:15, Karl via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I would like to make it a requirement if not inside a protocol extension which declares a conformance, and actually build the protocol name in to the member in an ABI-breaking way. We could make it additive by generating forwarding thunks from the old symbols to the new ones, but it would be better if we could just solve the overlapping-members problem before then.
> 
> That would mean you never get collisions between protocol members. There’s loads of amazing stuff we can do with that ability, and ways we can extend it to reduce a lot of boilerplate that occurs when you want to have multiple representations of the same data (String is just an example).
> 
> I don’t really care about the syntax we need to make it liveable. We could automatically insert the protocol names for unambiguous members at call-site, or something else.
> 
> This thread was originally about making the *syntax* a requirement; I agree with that, and I would actually take it one (or several) steps further, solving other problems along the way.
> 
>> On 22 Sep 2016, at 06:46, Russ Bishop <xenadu at gmail.com> wrote:
>> 
>> 
>>> On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>> on Tue Sep 20 2016, Karl <razielim-AT-gmail.com> wrote:
>>>> 
>>>> I think the best way is to prefix the member name with the protocol, e.g:
>>>> 
>>>> protocol MyProto {
>>>>  var aVariable : Int
>>>>  func aFunction()
>>>> }
>>>> class MyClass : MyProto {
>>>>  var MyProto.aVariable : Int
>>>>  func MyProto.aFunction() { … }
>>>> }
>>> ...
>>>> CC-ing Dave A, to understand better if this fits with the vision of protocols
>>> 
>>> I generally agree with Doug.  The canonical way to indicate “this
>>> method/property/type implements a requirement of protocol P” should be
>>> to define the entity in an extension that also adds conformance to P.
>>> If that's inadequate indication in some way we should find a way to
>>> enhance it.  I wouldn't mind the notation above, but only as a fallback,
>>> not a reuquirement.
>>> 
>>> -- 
>>> -Dave
>>> _______________________________________________
>> 
>> Indeed this is exactly how C# handles Interfaces (protocols). The default is the exact same way Swift works - by matching names. If there is a collision you specify Protocol.memberName. Its simple and in the years I was writing C# code it was flexible enough to cover most reasonable scenarios, without adding a bunch of boilerplate.
>> 
>> Russ
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution