Autogeneration of static func == for Identifiable & Equatable types

Hi all,

I think it would be cool if types, which are conforms Identifiable and Equatable protocols would have auto generated implementation of == operator.

My main point that if type already have and identifier (conforms Identifiable) and Equatable at the same time, it makes sense to to provide default == implementation kinda:

static func == (lhs: Self, rhs: Self) -> Bool {
    lhs.id == rhs.id
}

and not bother developer with that:)

What do you think?

No. That is actually the opposite of what the Identifiable protocol is for; it’s there to tell you that two objects which are not equal represent different versions of the same abstract thing.

If you have code that looks like that snippet, it’s basically guaranteed to be wrong.

12 Likes

In particular, a sensible implementation of == for Identifiable would compare every field except id.

This isn’t sensible at all. The value represents a snapshot of the state of a particular entity. It is not equal to any snapshot of the state of a different entity even if all of that state compares equal. I can imagine it being convenient to be able to compare the state of different entities but that operation should not be spelled == on an Identifiable model.

4 Likes

Thank you for such elegant and laconic explanation, sir :clap:

I have one more question: is it worth to create any mechanism to describe that entity can't conform some protocol or be derived from class?
If such thing existed, it would be easier to add constraint to keep hierarchy more safe, because now it's very easy to shoot yourself in the foot with it and Xcode wouldn't warn you about it.

What do you think?

@anandabits your opinion also is very interesting for me

I don't quite follow the question. Can you try phrasing it a different way?

Sure!

I've mean is something like:

struct SomeEntity: Equatable ***except*** Identifiable
{
}

make sense? except here tell us that SomeEntity can't conform to Identifiable protocol.

My understanding is that negative constraints are intentionally not supported and never will be.