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

Douglas Gregor dgregor at apple.com
Fri Mar 4 22:32:34 CST 2016

Sent from my iPhone

> On Mar 4, 2016, at 1:24 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Mar 4, 2016, at 10:49 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Mar 4, 2016, at 10:09 AM, Shawn Erickson via swift-dev <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. 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.
>>> 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.
>> Folks, this is obviously a language design discussion.  Please do this sort of thing on swift-evolution.  I’ve moved swift-dev to BCC.
> Even without language support, you can model optional protocol conformances as optional property requirements, with pretty much the exact same behavior on the user side that we give officially optional requirements:
> protocol OptionalMethod {
>   var optionalMethod: Optional<() -> ()> { get }
> }

One issue with this modeling is argument labels. You can't really have a bunch of properties name "tableView". 

> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160304/135bf092/attachment.html>

More information about the swift-evolution mailing list