The proposal was positively received as addressing a common need for which a standard protocol is appropriate.
During review, there were some concerns about the use of the property
id, with some preferring
identifier to avoid clashes with existing properties, while others stated they would have the same problem with
id. The core team feels that
id, as the term of art, is the better choice. Future language features should provide a path to resolve clashes.
The other concern raised was regarding the default implementation using
ObjectIdentifier for classes. Some felt this would lead to issues since object identifiers can be re-used if stored beyond the lifetime of the object. The core team believes this is a specific case of a more general class of problem: that the protocol leaves the duration of the identity unspecified. Identities could be guaranteed always unique (UUIDs), persistently unique but only per environment (database record keys), per-process unique within limits (Combine's identifiers are like this), for the lifetime of the object (object identifiers) or just unique within the current collection. It is up to both the conformer and the receiver of the protocol to document the nature of the identity. There is future potential to refine the protocol further if other guarantees prove useful in future.
While providing a default implementation could lead to bugs from conformances where it isn't appropriate, the documentation will be clear on the default implementation's limitations, and encourage conformers to replace it with a more appropriate ID if one is available. As ever, to conform to a protocol you must read the documentation to ensure you understand the requirements. In this respect
Identifiable's default for classes is similar to
RandomAccessCollection, which imposes no compile-time requirements over
BidirectionalCollection but does require you adhere to other requirements.