SE-0258: Property Wrappers (third review)

[Lantua]

@DevAndArtist

can you provide an example what you had in mind with such behavior or pin point me to a post I might have forgot about? I currently don‘t understand why we would want to initialize the projected value instead of the wrapped value.

@DevAndArtist I think it was around Pitch 3 when I pushed for the wrappedValue and projectedValue to both be projections from base storage. Both were on relatively equal footing back then (similar to now).

Nevertheless, I was also thinking that it'd be useful when projectedValue is not a one-off type, but normal type that is useful outside Property Wrapper itself (think UnsafeMutablePointer mocking example in the proposal). So that we can have the value be created outside, then consumed by the wrapper. It would be rather common for boxing types.

@Douglas_Gregor

For example, we could extend it to "if exactly one wrapper type has a projectedValue , use that for the $ property"

I was the one pushing for it in the beginning, but I now think current design ($ refers to outermost one only) is a good one. The more I think about how composition works, the less I think accessing inner projectedValue is a good idea. It bypasses outer wrapper and uses internal value directly. Those outer wrapper will likely want to know when other parts of the program access the wrapped value, which is not the case when we directly access inner wrapper directly. It's pretty similar to Law of Demeter at play here.