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

[Shawn Erickson]

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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160304/3d28fed2/attachment.html>