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 <xen...@gmail.com> wrote:
>> On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution 
>> <swift-evolution@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

Reply via email to