# \[Pitch #2\] Property Delegates by Custom Attributes **URL:** \ **Category:** Pitches\ **Created:** [April 9, 2019, 8:45am UTC](https://forums.swift.org/t/pitch-2-property-delegates-by-custom-attributes/22855 "2019-04-09T08:45:05Z")\ **Posts on this page:** 1\ **Showing post:** 31
**Author:** ![michelf](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michelf/32/1180_2.png) [@michelf](https://forums.swift.org/u/michelf)\ **Post date:** [April 9, 2019, 8:03pm UTC](https://forums.swift.org/t/pitch-2-property-delegates-by-custom-attributes/22855/31 "2019-04-09T20:03:51Z")
> [@Douglas\_Gregor](#): > > Yes, the built-in lazy avoids storing the closure by effectively inlining it into the getter. Did the proposal not make this sufficiently clear? I was simply pointing out to @DevAndArtist that access to `self` wasn't the only advantage of the built-in `lazy`. More generally, I'd say the `Lazy` and `UserDefault` examples highlight a shortcoming of the proposal by forcing things to be part of the storage when they shouldn't. They're what I call bad examples of things you can do with a property delegate. You want a property "delegate" but you need an instance of the delegate for every instance of the property, so anything the delegate needs has to be duplicated everywhere. I'd be happier if the delegate and the storage were two distinct types: the delegate containing things that need to be stored _once_, statically, and the storage (provided by the delegate) storing the data of the property (if any) within its container. I suggested something like this [earlier](https://forums.swift.org/t/pitch-property-delegates/21895/224), but I'm not sure anyone noticed. It's more complex and has to forgo subscript access (because no `inout` parameters in subscript), but the two-separate-types aspect is rather convenient. Maybe I should try harder to fit the subscript in that design... --- _[View the full topic](https://forums.swift.org/t/pitch-2-property-delegates-by-custom-attributes/22855)._