If your not the creator of the wrapper type then no, module clients are not allowed to retroactively extend wrapper types they don‘t own with projections like projectedValue, because they don‘t have access to the private backing storage the compiler creates for the module wrapped properties.
One could argue that it should be possible on your own properties that you wrap, but that can be left for future discussion. (See my next post.)
I must apologize for some confusion, I will edit my previous post. The nesting wrapper does not need to expose the access because the nested wrapper type will be accessible through its wrappedValue. Therefore you only need to traverse through outermost wrapper and all the nested wrappedValue up to the wrapper type of your interest and explicitly access its projectedValue.
I omit initaliters for the simplicity of the example:
@propertyWrapper
public struct W<Value> {
public var wrappedValue: Value
// this property is optional to implement
public var projectedValue: AnyTypeYouWant
}
@propertyWrapper
public struct IntWrapperWithStringProjection {
public var wrappedValue: Int
public var projectedValue: String { "\(wrappedValue)" }
}
public struct Example {
@W @IntWrapperWithStringProjection
public var value: Int = 42
// results into
private var _value = W<IntWrapperWithStringProjection>(initialVakue: .init(initialValue: 42))
public var value: Int { ... }
// likely wrong type, see my post bellow
public var $value: AnyTypeYouWant { ... }
public func getInnerStringProjection() -> String {
return _value.wrappedValue.projectedValue
}
}
Edit: I will edit this example when I get a clarification on the projection rule on composed wrappers (see my post bellow).