relates to:

• SR-5218 private(set) should block WritableKeyPath
• SR-6301 Creating a read-only KeyPath creates a WritableKeyPath (but still read-only)

Issue Description:

The use of WritableKeyPath on self crashes inside an init method unless self is already initialized. Put this very simplified example in the playground:

struct Foo {
let bar: Bool
init() {
let path: WritableKeyPath<Foo, Bool> = \Foo.bar // this works
self[keyPath: path] = true // crashes
}
}

let foo = Foo()

Of course our real use-case scenario is nothing similar to this basic example; we are passing arrays of key paths into the init method and iterating through them. It's very awesome but it seems non-ideal to have to specify a default value for every property (or provide a prototype to clone from).

Using var instead of let here does not help.

If ANY of the properties don't have a default value, then ALL of the WritableKeyPaths will crash – even ones that point to properties that do have default values. Also, since there is no way using reflection to determine at runtime which properties have default values and which don't, it doesn't seem like there is a workaround other than giving every property a default value.

This bug prohibits using "let" for values that you want to init with a keypath. Alone this makes it a really bad bug forcing bad compromises when using keypaths in functional programming patterns.

I hope we can find a solution to use WritableKeyPath during init. I'm not sure why it would care that the value is not initialized since we're inside an init method and therefore we should not expect it to be initialized yet.