Hello,
One can't define an Identifiable
type with a IUO id:
// Error: Type 'Player' does not conform to protocol 'Identifiable'
struct Player: Identifiable {
var id: Int!
}
// Error: Type 'Player' does not conform to protocol 'Identifiable'
struct Player: Identifiable {
typealias ID = Int?
var id: Int!
}
This can be bothersome for some people.
This sounded like a fun game to me, so I tried to achieve it anyway (implement Identifiable
conformance with an IUO id
). What I came up with is:
struct Player: Identifiable {
// Neat: IUO
var id: Int!
// Identifiable conformance
typealias ID = Int?
@_disfavoredOverload // Avoid ambiguity between the two ids
@_implements(Identifiable, id) // Tell Identifiable where to look at
var optionalID: ID { id }
}
THIS IS NOT A RECOMMENDED TECHNIQUE, because of the use of two underscored compiler attributes that are not part of the public language interface.
This works in all situations I could check, with direct use of the identifiable type, and in generic contexts:
func printID<T: Identifiable>(_ t: T) {
print(t.id)
}
var player = Player()
printID(player) // prints "nil"
player.id = 12
print(player.id + 1) // prints "13"
printID(player) // prints "Optional(12)"
I was unable to prevent the optionalID
property from showing up in autocompletion, though.
I wonder what language lawyers think here:
- Is support for IUO-backed optional associated types lacking in
Identifiable
, and other similar protocols? After all, since SE-0054, IUO are no longer a type: only their genuine optional facet can be used as an associated type. Should I open an issue? - If not (meaning that IUO support will never come ready made), is support for non-underscored workarounds desirable?
cc @Ben_Cohen (you were the review manager of SE-0261 - Identifiable Protocol).