This is essentially what I proposed in the "Compositional Initialization" pitch, however I think that pitch was not focused enough on this core aspect, which seems to me like a foundation upon which some very powerful and nice patterns could be built.
One aspect of that prior pitch that we would likely need, is a new type that provides a typesafe, type-eraseable wrapper around a KeyPath-Value pair. In the prior pitch, I gave an example Playground where this new type was called a "Property," (however I'm not sure that's a great name for it—I'm sure we can think of something better). There is also a working implementation of a failable init method that takes in a variadic argument of "Property" type, and tries to create the object, using Mirror to determine which non-optional children must be initialized.
However the current limitations of Swift still require a default value for any variable that would be initialized this way, which is not really ideal since you are wasting processor cycles to initialize those variables only to never actually use those values. Some types you may want to initialize only once because their initialization incurs a performance hit, or because you want the ivar immutable.
More important to me is the case of using keypaths for dependency injection. Current Swift DI frameworks rely on a bunch of gymnastics like code-generation to make sure we're setting the right values on the right types and to "validate the DI graph".
I might suggest however that if we could use keypaths in the manner described above, then it might alleviate the need for these extra curricular activities, since keypaths already provide the same abilities and guarantees—with the sole drawback that they cannot be used to initialize properties, and so any DI scheme based on them would require default values for everything.
While that may not be a bad compromise, still, I wonder if we might be able to improve upon this.