Below is one solution people have settled on: instead of storing a bag of erased key paths and later trying to “undo” the erasure by passing along dummy type hints, capture the “set‐to‑nil” behavior at the point where you have the strongly typed key path. In other words, build a type–erasing wrapper that already knows how to nullify that property, so you never have to cast back later. For example:

SWIFTCopied
/// A type–erasing wrapper for “nullifying” a reference writable key path.
struct Nullifier<Base> {
    /// Performs a “nullification” on the base object.
    let nullify: (inout Base) -> Void
}

extension Nullifier {
    /// Creates a nullifier from a key path whose value is an Optional.
    init<Value>(_ keyPath: ReferenceWritableKeyPath<Base, Value?>) {
        self.nullify = { base in
            base[keyPath: keyPath] = nil
        }
    }
}

Now if your Foo type is declared as:

SWIFTCopied
class Foo {
    var name: String? = ""
}

var foo = Foo()

Instead of storing an [AnyKeyPath], capture the nullification behavior right away:

SWIFTCopied
let nullifier = Nullifier<Foo>(\.name)

Then later during your delete operation you can simply write:

SWIFTCopied
nullifier.nullify(&foo)

This design eliminates the need to “figure out” at call site what underlying key path type is hidden behind an AnyKeyPath and removes the awkward dummy parameter. Instead you build a small API around your key paths so that when you gather “delete rules” you’re really collecting wrappers that know how to perform the update. This approach is safe, expressive, and saves you from ugly casts.

---

Summary

Rather than trying to convert a type–erased key path back to a typed ReferenceWritableKeyPath (which requires awkward hacks like passing a dummy parameter for type inference), you can instead capture the intended mutation (nullifying the property) in a closure or wrapper type when you have the strongly typed key path. Then, you store that behavior (for example, in a Nullifier as shown above) and later execute it on your object.