+1 for the current revision. Thanks for the hard work in getting to this point.
A thought occurred to me on the topic of composition. With concepts separating underlying storage (
_foo) from projection (
$foo), I wonder if this provides an avenue for an explicit solution to the composition problem.
Suppose we have a
@propertyWrapper struct Composite<T, U> which exposes each underlying wrapper as properties on its projection?
So something like:
@Composite(Binding, Bar) var foo = 1
Now immediately, there are issues with this approach:There's no protocol to constrain the composed wrappers on, and without Variadic Generics there's a static limit to the number of composed wrappers anyway, but I wonder if someone smarter could make a similar conceptual approach work, or if this is something we could solve by extending the feature in the future.
But if something like that were possible, it could yield explicit structured access to the underlying wrappers without the nesting order ambiguities that were evident in previous composition concepts:
print(foo) // 1 print(_foo) // the `Composite` storage print($foo) // the `Composite` projection $foo.$bar // the `Bar` projection $foo.$binding // the `Binding` projection
Or maybe it's just a dumb idea