[swift-evolution] two protocols with the same method name

Wallacy wallacyf at gmail.com
Sun Jan 10 18:17:17 CST 2016


I Like this C#'s "Explicit Interface Implementation".
The cast to call is understandable, it's good, but just think about. If we
use "self.Marriageable.ring" or "variable.Marriageable.ring" will make more
symmetrical with the implementation? "dot protocol" can be used to all
"explicit call", ambiguous or not.

Em dom, 10 de jan de 2016 às 21:49, Andrew Bennett via swift-evolution <
swift-evolution at swift.org> escreveu:

> Sorry if this is already mentioned, but I quite like C#'s "Explicit
> Interface Implementation" approach:
>
> https://msdn.microsoft.com/en-us/library/ms173157.aspx
>
>
> Basically:
>
> var Marriageable.ring: String? { ... }
> var CallReceivable.ring: String? { ... }
>
> to call it you could do self.ring if it was unambiguous, otherwise:
>
> (self as Marriageable).ring
> (self as CallReceivable).ring
>
>
>
> On Mon, Jan 11, 2016 at 9:51 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > By giving warning simply for same name, it will be quite annoying when
>> the project run into this situation without any wrong. For example:
>> >
>> > protocol ForwardIndexType : _Incrementable {
>> >     @warn_unused_result
>> >     public func advancedBy(n: Self.Distance) -> Self
>> > }
>> >
>> > extension ForwardIndexType {
>> >     @warn_unused_result
>> >     public func advancedBy(n: Self.Distance) -> Self
>> >     @warn_unused_result
>> >     public func advancedBy(n: Self.Distance, limit: Self) -> Self
>> >     @warn_unused_result
>> >     public func distanceTo(end: Self) -> Self.Distance
>> > }
>> >
>> > protocol BidirectionalIndexType : ForwardIndexType
>> > extension BidirectionalIndexType {
>> >     @warn_unused_result
>> >     public func advancedBy(n: Self.Distance) -> Self
>> >     @warn_unused_result
>> >     public func advancedBy(n: Self.Distance, limit: Self) -> Self
>> > }
>>
>> Firstly, for methods and subscriptors the "name" would actually encompass
>> the entire signature, so `advancedBy(_:)` and `advancedBy(_:limit:)` would
>> not conflict because they have different signatures.
>>
>> Secondly, `ForwardIndexType` and `BidirectionalIndexType` are *not*
>> unrelated protocols—one of them conforms to the other. Thus, we can assume
>> that `BidirectionalIndexType` knows about `ForwardIndexType`'s `advancedBy`
>> methods and intends for its versions to have compatible semantics.
>>
>> If instead `BidirectionalIndexType` did *not* conform to
>> `ForwardIndexType`, and `RandomAccessIndexType` tried to conform to both
>> `ForwardIndexType` and `BidirectionalIndexType`, *then* we would get an
>> error, because two independent protocols would have declared `advancedBy(_:
>> Self.Distance) -> Self` methods and it's possible they meant for them to
>> have different semantics.
>>
>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160111/6c417668/attachment.html>


More information about the swift-evolution mailing list