Protocol requirement override class property

Using Swift
1

I've run into an unexpected scenario when adding conformance of UIView to a protocol that has a requirement whose name already matches a property on UIView.

I defined these protocols:

public protocol Anchorable {
    var layoutAnchors: LayoutAnchors { get }
}
public protocol LayoutAnchors {
    var center: CenterLayoutAnchor { get }
}
public protocol CenterLayoutAnchor: UIView {
    func constrain(to center: CenterLayoutAnchor)
}
extension UIView: Anchorable, LayoutAnchors, CenterLayoutAnchor {
    public var layoutAnchors: LayoutAnchors {
        return self
    }
    
    public var center: CenterLayoutAnchor {
        self
    }
    
    public func constrain(to center: CenterLayoutAnchor) {
        self.centerXAnchor.constraint(equalTo: center.centerXAnchor).isActive=true
        self.centerYAnchor.constraint(equalTo: center.centerYAnchor).isActive=true
    }
}

So I could do:

view1.layoutAnchors.center.constrain(to: view2.layoutAnchors.center)

However, UIView already has a center property that is of type CGPoint. And I'm finding that I'm not able to access the CGPoint property after adding the conformance of UIView to LayoutAnchors.

Is this documented?

2

Can you provide the code that tries to access the CGPoint version of center, and what error you get? Perhaps providing more type information in the context will help pick the correct overload.

3

The question is whether or not this behavior is documented. If you want to confirm that that's the case you can copy and paste the above code into a playground create a UIView then print its center property. You'll see that what's printed is a UIView because CenterLayoutAnchor is required to be a UIView and LayoutAnchors.center — conformed to by UIView — is a CenterLayoutAnchor.

4

Nobody can answer whether “this behavior” is documented without actually understanding what “this behavior” is. You’re describing symptoms, not behaviors.

5

That seems like semantics to me. The behavior is pretty clear: that adopting a protocol with a property of the same name of an existing property, and implementing it, results in the form of the property defined on the original class no longer being accessible using its property name on an instance of the type.

6

I think the docs would (and should, IMO) address a more general version of your question: whether lookup checks class inheritance or protocol requirements first. Experimentation shows that it checks classes first, which is a reasonable behavior because you can always upcast an instance of a class to one of its conforming protocols to hide the class hierarchy from the lookup algorithm.

In addition to this, Swift is documented to support type inference-based overload resolution, which is why I suggested adding more type information. You should be able to do view.center as CGFloat to call the center getter inherited from UIView, and view.center as CenterLayoutAnchor to call the center getter required by LayoutAnchors.