As I understand the feature, this is by design.
The problem is that some SaveAddress secretly means a different type in every declaration where it appears. The some SaveAddress that bindSaveAddress() returns thus is not necessarily the same as the some SaveAddress that is saveAddress’s type.
An unfortunate consequence of this proposal is that we end up with distinct types that have the same spelling in code. That’s confusing, and I hope the release version of the compiler will at least generate a better error message for it, as Joe Groff proposed here.
You raise a good question about assigning to uninitialized properties. I’m not even sure what this means under the current implementation of the feature:
private let saveAddress: some SaveAddress
What is the single concrete runtime type of saveAddress that we are making opaque here? There’s no initializer, and thus nothing to infer the type from. @Joe_Groff, should this code even compile?
The solution in your case (again, in my limited understanding) would be to either use an existential:
private let saveAddress: SaveAddress // not just some, but any SaveAddress
…or to use a hypothetical not-yet-supported syntax to bind that property’s type to the specific function that populates it:
private let saveAddress: #returnType(of: bindSaveAddress)
It would be great if the compiler could suggest these two as fixits. Unfortunately, the latter is (IIRC) not yet implemented or even formally proposed, and the former will currently not work if the protocol uses Self or associated types.
I do wonder it’s premature to release this feature without one or both of those solutions available.