[swift-dev] Is there an underlying reason why optional protocol requirements need @objc?

[Dave Abrahams]

on Fri Mar 04 2016, Shawn Erickson <shawnce-AT-gmail.com> wrote:

> Well one missed aspect is that the delegator can test if the delegate
> responds to the method and modify its logic to adjust to the reality (which
> could have reasonable optimization hanging off it). If you depend on
> default no-op you don't get that ability (at least as "easily"). ...it of
> course is intertwined with the runtime capabilities of objective-c.

All that testing puts too much burden on the client, IMO.  It's much
better to provide customization points with default behaviors that work
sensibly when not overridden.

>
> On Fri, Mar 4, 2016 at 9:16 AM Erica Sadun via swift-dev <
> swift-dev at swift.org> wrote:
>
>>
>> > On Mar 4, 2016, at 9:25 AM, Dave Abrahams via swift-dev <
>> swift-dev at swift.org> wrote:
>> >
>> >
>> > on Fri Mar 04 2016, Simon Pilkington <swift-dev-AT-swift.org> wrote:
>> >
>> >> This seems like a strange/unrelated restriction on what is quite a
>> useful feature.
>> >
>> > ...or an abomination.  What sense does “optional requirement” make,
>> > after all?!
>> >
>>
>> However oxymoronic,  I kind of get the point. If you want default no-op
>> behaviors, with
>> the option to override, which is what optional Objective-C requirements
>> really are, just
>> create protocol extensions.
>>
>> extension MyProtocol {
>>    func optionalMember() {} // nothing to do
>> }
>>
>> This guarantees that the member exists, can be called by all consumers,
>> but that there's a
>> default in place that frees the conforming type from actually having to
>> implement anything
>> unless it really wants to.
>>
>> -- E
>>
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>

-- 
-Dave