Identifiable in Swift 5.1
The Swift Evolution proposal for
Identifiable, SE-0261, was kept small and focused in order to be incorporated quickly. So, if you were to ask, “What do you actually get by conforming toIdentifiable?”, the answer right now is “Not much.” As mentioned in the future directions, conformance toIdentifiablehas the potential to unlock simpler and/or more optimized versions of other functionality, such as the new ordered collection diffing APIs.[…]
Normalization is the key to successfully using strings as identifiers. The easiest place to do this is in the initializer, but, again, if you find yourself repeating this code over and over, property wrappers can help you here, too. […] Unfortunately, the Foundation framework doesn’t provide a single, suitable API for URL canonicalization, but
URLandURLComponentsprovide enough on their own to let you roll your own[…][…]
As we’ve said time and again, often it’s the smallest additions to the language and standard library that have the biggest impact on how we write code. (This speaks to the thoughtful, protocol-oriented design of Swift’s standard library.)
Because what
Identifiabledoes is kind of amazing: it extends reference semantics to value types.
2 Comments RSS · Twitter
“Because what Identifiable does is kind of amazing: it extends reference semantics to value types.”
Erm, no. It extends reference identity semantics to value types, as long as you implement the id as a globally unique identifier. Other distinctions—pass by copy, no refcounting, no subtyping—remain firmly in place.
Plus, of course, half the value types in Swift’s stdlib turn out to be wrappers around reference types anyway. Be interesting to see how/if Identifiable takes those smoke-n-mirrors into account.
