Struct with weak member prevents synthesized Equatable

protocols

(Daniel Lindenkreuz) #1

When adopting Equatable in a struct, Swift usually synthesizes Equatable conformance if all struct members are Equatable as well. However, this seems to stop working when declaring a member as weak var:

// Error: Type 'Foo' does not conform to protocol 'Equatable'
struct Foo: Equatable {
    weak var x: Bar? // Removing `weak` fixes above error, type `Bar?` is fine
    var y: String
}

class Bar: Equatable {
    static func == (lhs: Bar, rhs: Bar) -> Bool {
        return true
    }
}

Why do weak members prevent this behaviour? Implementing Equatable performance by checking member equality one-by-one works without any further ado in the above example.


(Slava Pestov) #2

This is probably an oversight. Do you want to file a bug?


(Tony Allevato) #3

I don't recall anything in the implementation that would explicitly exclude weak properties; it definitely wasn't intentional. Would weakness of the property cause the conformance check of the type to fail somehow?


(John McCall) #4

If you did a check using the storage type of the property, yes, that will be a ReferenceStorageType for weak, unowned, etc.


(Daniel Lindenkreuz) #5

Everyone, thanks for the feedback. I filed a bug: https://bugs.swift.org/browse/SR-9827


(Daniel Lindenkreuz) #6

Update: this error also occurs with unowned var and unowned let.


(Suyash Srijan) #7

It’s fixed on master: https://github.com/apple/swift/pull/22143 :slight_smile:


(Slava Pestov) #8

As an aside, do you think ReferenceStorageType makes sense at all? Since we've been slowly chipping away at InOutType we might want to consider putting ReferenceStorageType on the chopping block next.


(John McCall) #10

Well, I think we definitely want RST in SIL. In the AST it’s a harder question; not modelling it in the type means that clients that do care (admittedly the minority) have to remember the declaration. But SIL has to pay attention to the declaration anyway (because of its abstraction pattern) so that isn’t really a big deal for it.


(Zf Hx Fr) #11

So, in which Xcode release may this fix be reflected?


(Suyash Srijan) #12

The one which ships with 5.1 (unless this fix gets cherry picked to 5.0 - in that case it should ship with 10.2)