Future directions of Property Wrappers

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.

@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
11 Likes