It’s probably the influence from iOS development where I have delegate
protocols like this one:
@objc public protocol _ContainerViewControllerDelegate: class {
@objc optional func containerViewController(_ containerViewController:
ContainerViewController,
willPerform operation:
ContainerViewController.Operation,
from oldViewController:
UIViewController,
to newViewController:
UIViewController,
animated: Bool)
@objc optional func containerViewController(_ containerViewController:
ContainerViewController,
didPerform operation:
ContainerViewController.Operation,
from oldViewController:
UIViewController,
to newViewController:
UIViewController,
animated: Bool)
@objc optional func containerViewController(_ containerViewController:
ContainerViewController,
willSet oldViewControllers:
[UIViewController],
to newViewControllers:
[UIViewController],
animated: Bool)
@objc optional func containerViewController(_ containerViewController:
ContainerViewController,
didSet newViewControllers:
[UIViewController],
from oldViewControllers:
[UIViewController],
animated: Bool)
}
Implementing noops for each function in an extension seems kind of a wrong
decision for a few reasons:
They don’t make sense, because either the receiver implements a function or
not. So optional functions provide a more natural solution to that problem.
We don’t have to pass unnecessarily any arguments to the top functions.
(Personal preference) I tend to avoid @objc in general.
I think there was some technical reason why we don’t have optional functions in
pure Swift yet, something that also affects dynamic if I’m not mistaken.
Think of the protocol from above as of an existential of a set of functions.
The problem is that, I don’t want to introduce a standalone protocol for every
function, so the client can decide which protocol it will conform to to avoid
these noops. Furthermore, it’s way easier to check for an optional function in
your control flow instead of dealing with default values delegate functions
with a more complex return type might have.
--
Adrian Zubarev
Sent with Airmail
Am 28. März 2017 um 07:31:50, Slava Pestov ([email protected]) schrieb:
On Mar 27, 2017, at 1:48 PM, Adrian Zubarev via swift-evolution
<[email protected]> wrote:
Assuming we’ll get that functionality, both var and let should satisfy the
protocol requirements right?
In theory, there’s no reason not to allow that.
If it is valid, could we potentially get optional functions in pure Swift as
well?
I mean, you can already do this:
protocol P {
var optionalRequirement: ((Int) -> ())? { get }
}
extension P {
// “default implementation"
var optionalRequirement: ((Int) -> ())? { return nil }
}
struct A : P {}
struct B : P {
let optionalRequirement: ((Int) -> ())? = { (x: Int) in print(x) }
}
But it’s kind of tacky.
If you think about it, “optional requirement” is an oxymoron. What’s your
use-case?
Slava
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
