I've made the following change to the proposed design:
- Overload resolution for property wrapper initializers will always be done at the property wrapper declaration.
I will change the implementation so that instead of initializing the property wrapper at the call-site or in the function body, the compiler will emit a property wrapper generator function (it already knows how to do this - this is how out-of-line initialization of property wrappers works today). So, the type checking of the property wrapper initializer will always be the same between the two models. The only difference is where the generator function is called from. I'll also add a description of this to the proposal - I think it helps with the mental model.
Additionally, I've added the following sections:
- The impact of formalizing separate property wrapper models
- Always preserve API property wrappers in generated Swift interfaces
- Compiler detection of API property wrappers
- Library-defined diagnostic notes for understanding API wrapper restrictions
The first section is an exploration of the impact of the API versus implementation detail wrapper distinction. All of the other sections are new future directions. I'm also still working on the Alternatives Considered section for @xwu 's suggestion.