Pitch: Property Delegates

[DevAndArtist (Adrian Meister)]

As clearly seen in the thread it took me quite a few iterations to come up with this. I think we don't even need a @propertyDelegate attribute at this point as it just creates noise if we were going such path. What does @propertyDelegate really gives us? In my opinion only restrictions on how we have to build the storage type, but even that is highly restricted and not flexible. All the storage types presented in the original proposal can be build without the need of the attribute.

I would go that far and claim that we can use key-paths to describe the origin of the storage and let the synthetization simply create key-path referenced links. Having also the ability to partly opt-out of the some synthetization will bring willSet/didSet observers back as those are simply an overriden set.

var property: T by <key-path-placeholder> {
  // synthetized
  get {
    return self[keyPath: storageKeyPath]
  }
  
  // synthetized
  // optionally if key-path is (reference-)writable
  set {
    self[keyPath: storageKeyPath] = newValue
  }
}

The only issue I have with this is the future of throwable accessors. See my concerns here:

Throwable accessors

How would key-paths work on throwable accessors? struct S { var a: Int { get throws { return 42 } } var b: Int { return 42 } } I cannot solve this problem in my head without new key-path classes and typed throws where when throws is omitted it equals throws(Never). func extract<Root, Value, Path, Error>( _ path: Path, from root: Root ) throws(Error) -> Value where Path: KeyPath<Root, Value>, Error: Swift.Error { return try root[keyPath: path] } Usage: let s = S() _ = try…

---

Your examples will translate to:

public var name by \._data.name {}
public var score by \._data.score {}
public var isFinished by \._data.flags[.isFinished] {}