Our hashes aren't that simple either ;-) - but imho that's too much off topic.
That isn't the only problem that's solved by the keypath-approach, and the solution in the pitch leads to a lot of indirection as well:
I know it's unfair to bring real-world experience to discussion ;-), but I recently worked in a project which had at least three variants of an
id-property - and that was really awkward.
Whenever you needed the id, you saw several options in autocompletion which all looked like a perfect fit, and that is just confusing.
So the name collisions many seem to fear would actually be the better case for me - because with two different names, you would have the decide which one to choose.
I don't think this is a good comparison, and nobody proposed to add such indirection for every protocol.
The thing is that adding a property for
Identifiable will lead to a lot of indirection as well - and it will be much more visible:
I expect that the majority of types that will conform already have an
id whose name is defined by the context.
When you have a JSON-format which has a
customerID, what are you going to do to become
Identifiable? Rename your field and diverge from your raw data, or add indirection and two names for the same thing? There's no obvious answer, imho there shouldn't even be the need to think about such questions.