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