[swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

[Adrian Zubarev]

I will consider your advice, it’s actually a replay good one. :) I guess it was the iOS development influence from Objective-C that let me write such not swifty delegates.



-- 
Adrian Zubarev
Sent with Airmail

Am 29. März 2017 um 04:07:38, Slava Pestov (spestov at apple.com) schrieb:


On Mar 28, 2017, at 12:10 AM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:

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)
}

This looks like a bad API to begin with. If I was designing something like this I would instead have a single containerViewController() method or something that takes a value which encodes the various states.

You could have something like this:

enum ViewControllerState {
  case willPerform(…)
  case didPerform(…)
  case willSet(…)
  case didSet(…)
}

Slava
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 (spestov at apple.com) schrieb:


On Mar 27, 2017, at 1:48 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170329/3c58af80/attachment.html>