> On Nov 25, 2016, at 12:06 PM, Nevin Brackett-Rozinsky via swift-evolution
> wrote:
>
> Protocol forwarding was discussed on-list near the end of 2015 in the thread
> “[swift-evolution] [Proposal Draft] automatic protocol forwarding”. Feedback
> was generally positive, though there were disa
Protocol forwarding was discussed on-list near the end of 2015 in the
thread “[swift-evolution] [Proposal Draft] automatic protocol forwarding”.
Feedback was generally positive, though there were disagreements about
whether the forwarder and/or forwardee should have to conform to the
protocol. Also
> In what way is this “hiding” protocol conformance? In the examples, MyClass
> is declaring conformance to A and B via the Useful protocol composition.
> Perhaps I should have made it clearer which bits are new/proposed: Only the
> implements word is new here, the protocol composition syntax (
Tino,
In what way is this “hiding” protocol conformance? In the examples, MyClass
is declaring conformance to A and B via the Useful protocol composition.
Perhaps I should have made it clearer which bits are new/proposed: Only the
implements word is new here, the protocol composition syntax (A & B
Kotlin has a imho really nice solution for this: Because constructor parameters
appear right after the class declaration, you can refer to them in the
inheritance-clause.
Protocol conformance is a quite important aspect of a type, so I'm not sure if
it wise to allow "hiding" it — and I hope the
I like that.
Have you considered the following?
protocol foobar {
func foo() …
func bar() ...
}
class A: foobar { …}
class B: foobar {
let a = A() implements foobar.foo
let b = A() implements foobar.bar
}
Regards,
Rien
Site: http://balancingrock.nl
Blog: http:/
We already have a great way to compose APIs using protocol composition, and
we can supply default implementations for protocol methods, but what if we
want to compose implementations from existing types?
Say I have two disparate protocols:
protocol A {
func methodA1()
func methodA2()
}pro
