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

[Dave Abrahams]

on Fri Mar 04 2016, Shawn Erickson <swift-dev-AT-swift.org> wrote:

> (Sorry I hate top posting but fighting with Google inbox to avoid it)
>
> In delegation patterns it can be very helpful in terms of optimization
> (performance and memory) if the delegator can interrogate a delegate to
> know if certain delegation points are needed or not. I have code that has
> done this interrogation at delegate registration allowing potentially
> complex code paths and/or state maintenance to be avoided. 

There's always a way to do this kind of thing without making the
requirement itself optional.  For example, you can wrap the return type
in an Optional and have the default implementation always return nil, or
you can have the method accept a closure passed by the caller that
represents the extra work one would have to do in case the “optional
requirement” were supplied, and make sure it's called in any non-default
implementation, etc.

> It also could do impl caching to improve dispatch (did not support
> after registration "reconfiguring" delegates in this model purposely).
>
> Under objective-c leveraging optional protocol methods and runtime checks
> for responds to those was one built-in way for that. It also could add
> boilerplate code to check before dispatch that was potentially error prone
> and cumbersome. ...hence why I often did the check and configuration at
> registration in my code often avoiding peppering code with dispatch checks.

Not sure what you have in mind in any of the text above; I think I'd
need to see examples.

> Anyway not attempting to state anything for against this question about
> optional requirements in swift protocols. ...a handful of reasonable
> patterns exist in swift that allows one to achieve the same thing in safer
> and likely more performant ways.

IMO “optional requirements” only express things that can already be
expressed in other ways, add complexity to the language, weaken the
concept of what a protocol is, and worst of all, encourage the creation
of weak abstractions.  I don't doubt they've been useful to people in
the past but that doesn't mean they should be in the language.

It sounds on the surface like maybe you don't disagree with me here, in
which case there's not much more to say about it(?)

>
> -Shawn
>
> On Fri, Mar 4, 2016 at 9:38 AM Dave Abrahams <dabrahams at apple.com> wrote:
>
>>
>> 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
>>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-- 
-Dave