And it may prevent to implement an optimal implementation of hash(into:) especially when users of the identifiable type is different from people who implement the type as I described in the post #69.
I suppose the Hashable constraint works well in practice. I care about Hashable constraint is not opt-in and we have no means to invalidate it like nonmutating for computed properties' set although the downside of the Hashable constraint is unclear. I prefer keeping things minimal and believe that it prevents unexpected problems.
I am neutral on the suggestions to rename the associated type to Identifier. One possible motivation for doing that is that a lot of people use a strongly typed ID<Scope> as a concrete identifier type. Renaming the associated type could mitigate some potential confusion.
I am pretty strongly opposed to renaming the id property itself. This abbreviation is pervasive in the industry in my experience. Writing out identifier or identity is more verbose and will be less immediately familiar.
I don't think serialized formats should have carry any weight at all here. IMO it is usually not a good idea to allow serialized formats to influence the design of your model types. When people do implement model types that mirror serialized formats there are an unlimited number of possible names. A projection is often going to be required regardless of what name the protocol uses.
Not something I want to answer. Ruin the proposal as much as you want by totally ignoring the target data and people, but without me. That would be energy waste.
I'm not sure what you mean by "ignoring the target data and people". But please try to be constructive with your feedback instead of resorting to comments like "ruin the proposal". If you know of cases where the name id would cause problems larger than having to write an additional computed property please spell them out in more detail.
This is already a huge problem and I worry you are unable to see it. It is just rude to mess with people's code.
If my domain objects have existing identifier properties, I want to use those properties by their name. If I want to use a generic algorithm that needs an identifier, I don't want to have to refactor anything or get invaded with an id nobody asked for.
And let's also remind that not all identifiers are numbers, strings, or generally some scalar value. Tuple or struct can be identifiers too (think of database primary or unique keys that span multiple columns). Again, the name id would be a bad fit.
I would like to also add my agreement with so many others that the property should not be named id. If this were coming with Swift 1 or 2, then it might have been a valid proposal. Now that this is looking at going into Swift 5 it would be massively source breaking to name this id. I can think of at least 3 different personal projects that all use an id property that would collide with this proposal. There are probably hundreds, if not thousands of other projects in the same boat as me.
It seems a really bad idea to knowingly create such a massive collision in the standard library this late in the game. I see no reason how a more verbose name (like identifier) could not be used or how it would be "less immediately familiar."
Existing source compatibility is something that should definitely be taken into consideration during a proposal's pitch and its review and cannot be lightly tossed aside.
What if my domain objects have a differently named existing identifier property? My identifiers tend to be named id, so identifier or identity as you proposed would ruin the proposal and mess with my code ;)
Then you're all good. What is interesting is when your existing identifiers are NOT called id, but instead have a name which is close. Or when your models have various kinds of identifiers and you want to reserve id for one only one kind of identifiers (the numerical ones, for example, as opposed to the uuid identifiers).
How would this cause a problem for your projects? It will not cause a problem if your type does not conform to Identifiable and it will not cause a problem if your type does conform, but wants id to be the identifying property.
If there are types that need to conform to Identifiable which use id to mean something other than the identity they need to expose via Identifiable I think we need concrete examples to consider. I can't imagine why a type would be written that way but admit it's possible. Please share some code so we can understand where you're coming from better.
Because now my existing types couldn't conform to the new protocol without changing their existing id property. Perhaps source compatibility isn't the best way to phrase it, but if a user's id property on their new types doesn't match perfectly with the expectations required by the new protocol then they cannot simply add conformance to the new protocol without breaking changes to their library.
id is a very common name and an existing object's current id property may not be usable for record identity with the new protocol. Other examples have been given up thread where id could clash or cause confusion. Renaming a property that already exists and is used pervasively throughout a library (not to mention all the other parties which are using the library) is not going to be a simple task.
I have a personal path library which gives paths an id attribute based on the device id where the file is contained (using stat(2) C APIs). This is clearly not valid for record identity and I have a dozen projects using my path library in various capacities. Not all of those are using a path's id attribute, but some are and I would have to audit each library to use whatever new variable name I choose.
I have a hard time believing that I am the only person out there with an id attribute that wouldn't be usable for this new protocol. The subset of people on this one thread does not necessarily reflect all swift developers.
Perhaps this is all my own fault for using the name id in a bad place, but when I started writing my path library a year and a half ago this Identifiable protocol wasn't a thing...
Thank you for continuing to contribute to the discussion. This comment explains where you are coming from better. Can you give a more complete and concrete example of a model like this, explaining what role each identifier plays and what an appropriate conformance to Identifiable would look like for these types?
But also, isn't what you describe a feature and not a bug? If your type has an id property, but it does not fit the semantics of Identifiable.id, then your type shouldn't conform to Identifiable because its notion of identity is incompatible with that of Identifiable. The act of conforming is the statement that your type's id has the semantics required for record identity.
Is it really necessary that you give me more work to do? It looks like you have started to see that blessing id is a bad idea. Keep on the good work: draw conclusions, improve your proposal!
As a little side-note: id is a keyword in objc, so I have seen a bunch of objc code (and Swift code introduced to those codebases) using identifier in its stead. The same problem will probably occur for some folks no matter what name we choose. The history of id not being a valid property name in objc might even help.
Keep in mind that I will not be making any decisions. Youâre presenting a case to the core team. It will be stronger if you provide more concrete information for them to consider. But itâs up to you.
This doesn't make much sense. If I have a type with a property id, that has nothing to do with whether or not I might I want to make it conform to Identifiable. As has been noted, id is a common property name for a variety of uses and the fact that it's use doesn't coincide with Identifiable's will likely be rather common. That doesn't mean that I couldn't, in the context of my app, create some notion of identity for the value that works just fine with Identifiable. Given the common use of id already noted, it makes much more sense to name the requirement something else.
A good point, but I feel like this number decreases the longer swift has been public and more objc libraries are replaced with pure-swift implementations.
It's more than just my type shouldn't conform to Identifiable, but it cannot conform to Identifiable without breaking changes. id is too common of a name for every potential use of it to meet the Identifiable criteria. Longer names like identity or identifier are less likely to be used and would therefore have less potential for collisions.
Regardless of what you propose to the core team, these alternate names should be added to the "Alternatives Considered" section. Even if you personally reject them for your proposal, they were still discussed/considered (however briefly ).
That's what I'm asking you to consider: isn't it a feature that should not becomes cannot through the name collision? It's exactly because it's the most commonly used name for identity that this is a feature: id is used for many different notions of identity, but a type that conforms to Identifiable would all share the same notion of identity through its id property.
).