如何在Swift KeyPath的类型为KeyPath时获取基础值 <Root, Value!> ？

Question

Take a look at the following code:

struct Something {
  var s: String! // Implicitly Unwrapped Optional
}

func bind<T, V>(keyPath: WritableKeyPath<T, V?>) {
}

bind(\Something.s)

The code above does not compile. If we change the signature of bind to bind<T, V>(keyPath: WritableKeyPath<T, V>) then it does compile, but the problem is that the type of V is String! and I need to get the underlying type, in this case String .

We can solve the problem as follows:

func bind<T, V>(keypath: WritableKeyPath<T, ImplicitlyUnwrappedOptional<V>>) {
}

Unfortunately the documentation says that ImplicitlyUnwrappedOptional is deprecated. However, it is not marked as deprecated with the @available attribute.

I'm hesitant to use a type that the docs say are deprecated, but I can find no other way to accomplish what I need.

1. Is there another way to get the implicitly wrapped generic Value type from a WritableKeyPath when its type is WritableKeyPath<T, V!> ?
2. Will ImplicitlyUnwrappedOptional be removed at some point?

Answer 1

Is there another way to get the implicitly wrapped generic Value type from a WritableKeyPath when its type is WritableKeyPath<T, V!> ?

Not that I'm aware of. Really the problem here is that \\Something.s shouldn't be a WritableKeyPath<T, V!> . That should be illegal under the rules set out by SE-0054 (IUOs are attributes on declarations; they're not actual types that can satisfy generic placeholders).

Instead, \\Something.s should be a WritableKeyPath<T, V?> , so really your original code ought to compile. This issue has been filed as a bug here .

Will ImplicitlyUnwrappedOptional be removed at some point?

Yes, this is set out by SE-0054 :

Because IUOs are an attribute on declarations rather than on types, the ImplicitlyUnwrappedOptional type, as well as the long form ImplicitlyUnwrappedOptional<T> syntax, is removed. Types with nested IUOs are no longer allowed. This includes types such as [Int!] and (Int!, Int!) .

However the type-checker implementation for this wasn't fully implemented for Swift 4, which is why you're still able to use ImplicitlyUnwrappedOptional as a type in order to work around your problem. It has been implemented for Swift 5 though , so your workaround will no longer compile on its release.

Although hopefully the IUO key path bug will have been fixed by then.