# Future directions of Property Wrappers

**URL:** <https://forums.swift.org/t/future-directions-of-property-wrappers/27934>\
**Category:** Discussion\
**Tags:** propertywrapper\
**Created:** [August 15, 2019, 8:29pm UTC](https://forums.swift.org/t/future-directions-of-property-wrappers/27934 "2019-08-15T20:29:02Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [February 27, 2020, 7:56pm UTC](https://forums.swift.org/t/future-directions-of-property-wrappers/27934/18 "2020-02-27T19:56:56Z")

</div>

The labels and the parameter names aren't perfectly aligned with the current design of property wrappers that is true. However `wrapped wrappedKeyPath` is still needed for a simple reason. You have to be able to disambiguate between the static subscript which returns the wrapped value vs. the static subscript that returns the projected value instead.

I had some short conversations on Twitter with @Joe_Groff, @Douglas_Gregor and @jrose and I no longer think that the privately available feature should ever become available as the final way on how we would access `self`.

However the ideal solution will only be available in the long term as it would require generalized coroutines.

```swift
@propertyWrapper(static)
struct W<Value> {
  static func read<T>(from instance: T) -> shared Value { ... }
  static func modify<T>(in instance: inout T) -> inout Value { ... }
  // combined with some of the upthread ideas
}

```

Something like this would allow us multiple things:

- We could share constant values between static wrappers directly through the types that contain wrapped properties
- This would reduce the type of the types
- This would be an optimization for both value an reference types
- Types would contain only the necessary storages, not the property wrappers as they will be static
- The solution would be more generalized and more elegant
- It would obviously allow access to enclosing `self`
- It wouldn't contain the clattered static subscript syntax anymore

---

_[View the full topic](https://forums.swift.org/t/future-directions-of-property-wrappers/27934)._