这里有一个非常简单的例子，只适用于swift类，而不适用于结构或枚举。 注意，协议方法是可选的，有两个级别的可选链接。 同样，采用协议的类在声明中需要@objc属性。

@objc protocol CollectionOfDataDelegate{
   optional func indexDidChange(index: Int)
}


@objc class RootView: CollectionOfDataDelegate{

    var data = CollectionOfData()

   init(){
      data.delegate = self
      data.indexIsNow()
   }

  func indexDidChange(index: Int) {
      println("The index is currently: \(index)")
  }

}

class CollectionOfData{
    var index : Int?
    weak var delegate : CollectionOfDataDelegate?

   func indexIsNow(){
      index = 23
      delegate?.indexDidChange?(index!)
    }

 }

1. 使用默认实现(首选)。

protocol MyProtocol {
    func doSomething()
}

extension MyProtocol {
    func doSomething() {
        /* return a default value or just leave empty */
    }
}

struct MyStruct: MyProtocol {
    /* no compile error */
}

优势

不涉及Objective-C运行时(好吧，至少没有显式地)。这意味着你可以使结构，枚举和非nsobject类符合它。此外，这意味着您可以利用强大的泛型系统。 当遇到符合这种协议的类型时，您总是可以确保满足所有需求。它总是具体实现或默认实现。这就是“接口”或“契约”在其他语言中的表现。

缺点

For non-Void requirements, you need to have a reasonable default value, which is not always possible. However, when you encounter this problem, it means that either such requirement should really have no default implementation, or that your you made a mistake during API design. You can't distinguish between a default implementation and no implementation at all, at least without addressing that problem with special return values. Consider the following example: protocol SomeParserDelegate { func validate(value: Any) -> Bool } If you provide a default implementation which just returns true — it's fine at the first glance. Now, consider the following pseudo code: final class SomeParser { func parse(data: Data) -> [Any] { if /* delegate.validate(value:) is not implemented */ { /* parse very fast without validating */ } else { /* parse and validate every value */ } } } There's no way to implement such an optimization — you can't know if your delegate implements a method or not. Although there's a number of different ways to overcome this problem (using optional closures, different delegate objects for different operations to name a few), that example presents the problem clearly.

2. 使用@objc可选。

@objc protocol MyProtocol {
    @objc optional func doSomething()
}

class MyClass: NSObject, MyProtocol {
    /* no compile error */
}

优势

不需要缺省实现。你只需要声明一个可选方法或变量就可以了。

缺点

它要求所有符合要求的类型都与Objective-C兼容，从而严重限制了协议的功能。这意味着，只有继承自NSObject的类才能符合这样的协议。没有结构，没有枚举，没有关联类型。 必须始终通过可选调用或检查符合类型是否实现了可选方法来检查是否实现了可选方法。如果经常调用可选方法，这可能会引入大量样板文件。

在协议中定义函数并为该协议创建扩展，然后为您想要作为可选使用的函数创建空实现。

与最初的问题有点偏离主题，但它建立在安托万的想法上，我想它可能会帮助到一些人。

您还可以为具有协议扩展的结构设置可选的计算属性。

您可以将协议上的属性设置为可选的

protocol SomeProtocol {
    var required: String { get }
    var optional: String? { get }
}

在协议扩展中实现虚拟计算属性

extension SomeProtocol {
    var optional: String? { return nil }
}

现在你可以使用实现或不实现可选属性的结构体

struct ConformsWithoutOptional {
    let required: String
}

struct ConformsWithOptional {
    let required: String
    let optional: String?
}

我还在我的博客上写了如何在Swift协议中执行可选属性，我会不断更新，以防Swift 2发布时情况发生变化。

一种选择是将它们存储为可选函数变量:

struct MyAwesomeStruct {
    var myWonderfulFunction : Optional<(Int) -> Int> = nil
}

let squareCalculator =
    MyAwesomeStruct(myWonderfulFunction: { input in return input * input })
let thisShouldBeFour = squareCalculator.myWonderfulFunction!(2)

我认为在询问如何实现一个可选协议方法之前，应该先问问为什么要实现它。

如果我们将swift协议视为经典的面向对象编程中的接口，那么可选方法就没有多大意义，也许更好的解决方案是创建默认实现，或将协议分离为一组协议(可能在它们之间具有一些继承关系)，以表示协议中方法的可能组合。

欲进一步阅读，请参阅https://useyourloaf.com/blog/swift-optional-protocol-methods/，该网站对此问题有很好的概述。