I agree with that. I believe I have more often run into name collisions for
protocols with differing semantics then matching semantics. Actually far
more often then both I have purposely used somewhat contrived naming in
protocols to avoid collisions, if that can be avoided by leveraging the
implicit namespacing that exists in the protocol's name; it would be nice
language feature IMHO.
On Tue, Sep 27, 2016 at 7:51 AM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:
>
> on Tue Sep 27 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:
>
> > While this solves the problem of overlapping names with different
> > semantics, how would you express the case where the names actually
> > have the same semantics, so that you only want to have one
> > implementor?
> >
> > protocol A {
> > func specficSemantics()
> > func sameSemantics()
> > }
> >
> > protocol B {
> > func specficSemantics()
> > func sameSemantics()
> > }
> >
> > struct C : A, B {
> > // these implementations have to be specific for A and B so Karl’s
> approach allows to differentiate them
> > func A.specficSemantics() { … }
> > func B.specficSemantics() { … }
> >
> > // this implementation should be shared by A and B because both
> share the same semantic here
> > func sameSemantics() { … } // ??
> >
> > // would I have to write it like that (manual delegation to the
> shared implementation)?
> > func sameSemantics() { … }
> > func A.sameSemantics() { sameSemantics() }
> > func B.sameSemantics() { sameSemantics() }
> > }
> >
> > -Thorsten
>
> The cases where you find these kinds of exact collisions are so rare
> (never in my
> career) that it's fine if some manual work is needed.
>
> --
> -Dave
> _______________________________________________
> 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
