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.
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?
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.
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.
