Re: [swift-evolution] [pitch] Implementation composition

> 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

Re: [swift-evolution] [pitch] Implementation composition

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.

Re: [swift-evolution] [pitch] Implementation composition

> 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

Re: [swift-evolution] Add code to super methods.

I agree. An NS_REQUIRES_SUPER equivalent was on my list of things to propose during stage 2, and I don't see a reason to enforce order. > On Nov 25, 2016, at 04:42, Tino Heth via swift-evolution > wrote: > > >> What are your thoughts on this? >> >> Just to throw

Re: [swift-evolution] [pitch] Implementation composition

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 &

Re: [swift-evolution] [pitch] Implementation composition

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

Re: [swift-evolution] [pitch] Implementation composition

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:

Re: [swift-evolution] Global init() functions

Why not just say that this doesn't affect the removal of types (i.e. they can still be discarded) and add something to prevent specific types being discarded even if they're not statically used? ```swift @nodiscard SomeType ``` This way, rather than a protocol opting in that anything

[swift-evolution] [pitch] Implementation composition

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()

Re: [swift-evolution] Add code to super methods.

> What are your thoughts on this? > > Just to throw out a strawman: > > // Warn if override doesn’t begin with “super.foo()” > __attribute(swift_requires_super_call_at_begin) > > // Warn if override doesn’t end with “super.foo()” > __attribute(swift_requires_super_call_at_end) I myself