[swift-evolution] Mark protocol methods with their protocol

Thu Sep 22 09:44:33 CDT 2016

On 22.09.2016 11:10, Jean-Denis Muys via swift-evolution wrote:
> 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

Actually I also support Karl's suggestion in general. It is trying to solve 
IMO important problems and make Swift's protocol programming safer and less 
fragile. Also it adds new interested features for working with protocols.

But in reality, I don't feel like his suggestion could be accepted by core 
team and community and even if it could be supported, it seems for me that 
*implementation* of his proposal requires a huge amount of time and big 
changes in how Swift is working currently. (Probably some one who knows 
Swift internals could comment regarding this)
So, theoretically we'd have these improvements not in near future and I 
think the problem discussed is very important to be addressed in Swift as 
soon as possible.
I base my opinion also on previous discussions regarding similar subjects.

My suggestion regarding a marker for protocol implementation method/prop in 
type - solves most of the addressed problems with protocol conformance and 
with fragile of such conformance, and adds one new keyword (or even zero - 
right now I think the `override` is better choice for such "marker"). I 
believe this proposal could be implemented with much less amount of work 
and with less changes to current internals of Swift and to current code 
base, and so we can have such a big improvement in Swift soon. So my 
intention was to suggest solution that can dramatically improve Swift's 
protocol programming with "small" amount of changes for compiler(internals) 
and for existed sources.

But it seems like the direction chosen by the core team and supported by 
many in community - is just a warning if extension conforming type to 
protocol contains unrelated to that protocol methods/props. I see that this 
solution can improve protocol programming in some areas, but does not 
address some IMO important issues we discussed in the thread :

* Currently extension can not have stored properties. So, if we want to 
implement protocol's props as stored properties - we can't move them to 
extension. So to implement this soulution - we need stored properties in 
extensions. It is not clear if and when they are expected.

* This solution will not require the safety(regarding protocol conformance) 
from a developer, it will only inform and only if protocol conformance 
defined in extension. So, when you use 3rd party source code - your project 
will not be protected for the discussed problems.

* To write safe code I can't group methods/props as I want, I have to 
declare a number of extensions per-protocol (in case my type conforms to a 
number of protocols)

* This solution does not solve problem of near-miss signature of method 
definition in protocol extension like here:
protocol A { func foo() }
protocol B : A {}
extension A { func foo() }
extension B { func voo() } // typo. how to "mark" this should be impl?
"my" suggestion:
extension A { override func foo() }
extension B { override func foo() }

* Not clear how to write safe code with that approach if we implement 
protocol requirement in derived class, but conformance was declared in base 
(but not implemented) :
protocol P { func foo() }
extension P { func foo() }
class A : P {}
class B { func foo() } // we can't move this to extension, B already 
conforms to P
, and in opposite to "my" `override` requirement for implementation, if `A` 
will add its own foo() implementation - we'll have to change B's 
definition(need to add `override` for B.foo )
"my" suggestion:
class B { override func foo() }

>
> 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
> _______________________________________________ swift-evolution mailing
> list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>