Cyclic loop between protocols in swift - swift

Question

I'm trying to define some protocols in a Swift file, however I've noticed that if the protocols have crossed references XCode becomes buggy and it's impossible to work with the project. The example of used protocols might be the one used below:
protocol VIPERPresenterProtocol
{
var view: VIPERViewProtocol? { get set }
var interactor: VIPERInteractorInputProtocol? { get set }
var wireFrame: VIPERWireFrame? { get set }
// /* Add your extra communication methods here */
// /* Presenter -> ViewController */
}
protocol VIPERViewProtocol
{
var presenter: VIPERPresenterProtocol? { get set }
}
Where the VIPERPresenterProtocol has a reference to the VIPERViewProtocol and this last has a reference to the VIPERPresenterProtocol.
This is something that works in Objective-C but that Swift doesn't like. My question is, is this something Apple doesn't expect to support in Swift, if it might be a bug of the Swift language or if I should implement this in any other way.

Answer 1

Your question has a form of:
protocol A
{
var b: B? { get set }
}
protocol B
{
var a: A? { get set }
}
However, while the two protocol declarations compile, any attempt to implement them as such does not:
protocol A {
var b: B? { get set }
}
protocol B {
var a: A? { get set }
}
// on their own, the two protocol declerations compile
class Ca: A { // Does not compile: --> Segmentation fault 11
var b: B?
}
This does not happen if we break the cycle:
protocol A {}
protocol B {
var a: A? { get set }
}
class Ca: A {}
class Cb: B {
var a: A?
}
let cb = Cb() // --> {nil}
cb.a = Ca() // --> {{Ca}}
cb.a // --> {Ca}
Or if we define the two protocols in terms of concrete types:
protocol A {
var b: Cb? { get set }
}
protocol B {
var a: Ca? { get set }
}
class Ca: A {
var b: Cb?
let i = "A"
}
class Cb: B {
var a: Ca?
let i = "B"
}
let cb = Cb() // --> {nil "B"}
cb.a = Ca() // --> {{{...}} "B"}
cb.a // --> {{nil "A"}}
cb.a!.b = Cb() // --> {{{...} "A"}}
My impression is that the type checker cannot yet deal with recursive type declarations. Whether it ever will, may be an open question even to Apple at this point, though, because of the clear intention to facilitate functional idioms, this must at least be a possibility.
I have answered a similar question before, though, as I eventually realised with the help of #newacct, not identical.
EDIT
I have just upgraded to Xcode 6.1 GM Seed and things have changed! The following snippet now compiles and appears to run fine!
protocol A {
var b: B? { get set }
}
protocol B {
var a: A? { get set }
}
class Ca: A {
var b: B?
}
class Cb: B {
var a: A?
}
let a = Ca() // --> {nil}
let b = Cb() // --> {nil}
a.b = b // --> {{{...}}}
b.a = a // --> {{{...}}}
(This improvement, however, does not extend to recursively defined associated types.)

Answer 2

I was trying to build something similar too for VIPER, and I encountered the same problems.
I add something to the good answer of milos: I succeeded to break the cycle even when using associated types, using a couple of supporting protocols.
protocol _VIPERViewProtocol {
}
protocol VIPERViewProtocol : _VIPERViewProtocol {
typealias P:_VIPERPresenterProtocol
var presenter: P! {get set}
}
protocol _VIPERPresenterProtocol {
}
protocol VIPERPresenterProtocol : _VIPERPresenterProtocol {
typealias W:_VIPERViewProtocol
var view: W! {get set}
}
This has the advantage of letting the compiler infer the right type of the associated presenter and view, for example:
class BasePresenter : VIPERPresenterProtocol {
var view : BaseView!
}
class BaseView : VIPERViewProtocol {
var presenter: BasePresenter!
}
var p = BasePresenter()
// p.view is correctly recognized as BaseView!
This is valid as long as you use an associated type. Since there is no covariance for properties in Swift, the above code would not compile if you change it like this:
protocol VIPERViewProtocol : _VIPERViewProtocol {
var presenter: _VIPERPresenterProtocol! {get set}
}
Anyway, stepping back to the VIPER architecture, this helps only for giving the concrete classes a template that they must implement.
It would be much more useful if we could define a "builder" method that takes the generic objects conforming to the protocols (wireframe, presenter..), and that wires up all the components.
Unfortunately, something like this doesn't work:
func builder(p:VIPERPresenterProtocol, v:VIPERViewProtocol) {
p.view = v
v.presenter = p
}
compiler complains about Protocol 'VIPERViewProtocol' can only be used as a generic constraint because it has Self or associated type requirements.
Maybe one solution to explore is generics, but I still have to think about it.