The LongTermStorage example has an interesting signature for its initializer:
init(manager: StorageManager, initialValue: Value) {
I can imagine wanting to be able to separate the "configuration" from the initial value. Instead of writing:
@LongTermStorage(manager: manager, initialValue: "Hello")
var someValue: String
It might be interesting to be able to say:
@LongTermStorage(manager: manager)
var someValue = "hello"
This becomes even more interesting when out-of-line initialization is used:
@LongTermStorage(manager: manager)
var someValue: String
// ...
// elsewhere, perhaps in an initializer body:
someValue = "hello"
If we had sugar like this, the Ref example I posted could relatively easily be modified to accept different storage configurations without exposing the backing storage directly while still supporting direct initialization of the delegating property:
@Ref(storage: .box)
var boxRef: String = "hello"
@Ref(storage: .longTerm(manager))
var longTermRef: String = "hello"
I'm posting this primarily to show that there may be solutions other than delegateValue to solving some of the intended use cases.
Further, in reading the text of that example closely, it specifically states:
A property delegate type can choose to hide its instance entirely by providing a property named
delegateValue
This sentence contradicts exposing a private $$foo to support out-of-line initialization of the instance. If delegateValue is intended to hide the instance completely then direct initialization is all that could be supported. If it isn't, then maybe some of the use cases suffer. I don't think we understand the use cases well enough yet to make a decision about which would be better.