# SE-0258: Property Delegates

**URL:** <https://forums.swift.org/t/se-0258-property-delegates/23139>\
**Category:** Proposal Reviews\
**Created:** [April 15, 2019, 4:30pm UTC](https://forums.swift.org/t/se-0258-property-delegates/23139 "2019-04-15T16:30:21Z")\
**Posts on this page:** 1\
**Showing post:** 76

<div class="post-metadata">

**Author:** ![kiel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kiel/32/1392_2.png) [@kiel](https://forums.swift.org/u/kiel)\
**Post date:** [April 18, 2019, 12:07am UTC](https://forums.swift.org/t/se-0258-property-delegates/23139/76 "2019-04-18T00:07:04Z")

</div>

> [@Jon\_Hull](#):
>
> Then you have full control over the storage. If you don't provide your own storage, then it would be synthesized by the compiler (but without an accessible name).

Completely agree. I also think a new keyword like `from` or `by` at the declaration site would do much to reduce verbosity and density:

> [@Pitch: Property Delegates](https://forums.swift.org/t/pitch-property-delegates/21895/228):
>
> With respect to exposing the storage using the $ syntax, could this be an alternative approach?
> 
> ```swift
> public var myProperty: Int from myStorage
> private var myStorage: AtomicLazy<Int>()
> 
> ```
> 
> The idea here is that implementations wanting access to the storage should declare and name a property that provides for another’s storage. Otherwise, the storage remains inaccessible:
> 
> ```swift
> public var myProperty: Int from AtomicLazy()
> 
> ```
> 
> What I like about this is the developer can express that the overall implementation of the type with the property with delegated storage should (or does) not manipulate the storage directly.

I'd also add that the synthesized storage would be still be accessible through runtime reflection.

---

_[View the full topic](https://forums.swift.org/t/se-0258-property-delegates/23139)._