[TypeChecker] Type wrappers (experimental feature)

[xedin]

Initial implementation of @typeWrapper attribute which could be used to declare a type
to "wrap" other types by routing all their stored property accesses through itself.

The type wrapper is very similar to a property wrapper but there are couple of fundamental
differences:

• Could only be associated with a class or a struct;
• Disables memberwise and default initializers, produces a special synthesized initializer that covers all the stored properties instead;
• All access to the stored properties is routed through a single instance of a type wrapper;
• A per-instance $Storage container allocates storage for all of the wrapped properties;
• Default initialization expressions are moved to the synthesized constructor;
• Access is performed via subscripts that accept key paths to the underlying storage.

Valid type wrapper has to have:

• A single generic parameter (i.e. Storage) which would be substituted with storage type;
• init(memberwise: Storage) - initializer that accepts a generic parameter of underlying storage;
• subscript<Value>(storageKeyPath path: {Writable, ReferenceWritable}KeyPath<Storage, Value>) -> Value -
  a subscript that would be called on every applicable property access.

Here is an example of a valid type wrapper declaration:

@typeWrapper
struct Wrapper<Storage> {
  var storage: Storage

  init(memberwise: Storage) {
    self.storage = memberwise 
  }

  subscript<Value>(storageKeyPath path: WritableKeyPath<Storage, Value>) -> Value {
    get { storage[keyPath: path] }
    set { storage[keyPath: path] = newValue }
  }
}

Now, let's see Wrapper in action to appreciate how much boiler place it removes:

@Wrapper
struct Person {
  var name: String
  var age: Int
}

Access to name and age of a Person is going to get routed through Wrapper type.

The transformed type looks like this:

struct Person {
  struct Storage {
    var name: String
    var age: Int
  }

  var _storage: Wrapper<Storage>

  init(name: String, age: Int) {
    self._storage = Wrapper(memberwise: Storage(name: name, age: age))
  }

  var name: String {
    get { _storage[storageKeyPath: \Storage.name] }
    set { _storage[storageKeyPath: \Storage.name] = newValue }
  }

  var age: Int {
    get { _storage[storageKeyPath: \Storage.age] }
    set { _storage[storageKeyPath: \Storage.age] = newValue }
  }
}

All of the boilerplate code required to create and maintain 1-1 storage between type and Storage and proper initialization is now handled by the compiler.

Open questions:

• Support for pre-existing user-defined initializers
• ✅ Support for stored properties with property wrappers

[LucianoPAlmeida]

Hey @xedin,
One question, consider this

@Wrapper
struct Person {
  var name: String
  let age: Int = 0
}

Since wrapper subscript is defined as WritableKeyPath and defines a set which cannot be applicable to a let property what would be the expected behavior in this case?

[xedin]

@LucianoPAlmeida properties like that are not currently wrapped.

[xedin]

A more interesting example is the one which uses a class as a let e.g.:

class X {
  var v: Int = 42
}

struct S {
  let x: X = X()
}

Since x is a reference type it would still be modifiable e.g.:

var s = S()
s.x.v = 0

I think this case would have to be wrapped but it would have to pick different overloads of subscript from type wrapper type...

[LucianoPAlmeida]

I think this case would have to be wrapped but it would have to pick different overloads of subscript from type wrapper type...

Yeah, from my understanding an overload of subscript that takes an WritableKeyPath would not work in that let reference case, so user would have to implement a ReferenceWritableKeyPath overload of the subscript.

let wkp: WritableKeyPath<X, Int> = \.v
let rwkp: ReferenceWritableKeyPath<X, Int> = \.v
let s = S()
s.x[keyPath: wkp] = 0 // error: cannot assign through subscript: 'x' is a let constant
s.x[keyPath: rwkp] = 0 // ok

Is that what you mean by different overload?

[xedin]

Is that what you mean by different overload?

Yes, it's currently modeled as implicitly generated AST so type wrapper could define multiple overloads of subscript and type-checker would just pick one that works for synthesized code.

[LucianoPAlmeida]

Yes, it's currently modeled as implicitly generated AST so type wrapper could define multiple overloads of subscript and type-checker would just pick one that works for synthesized code.

Ah got it, Thanks!

[xedin]

@swift-ci please clean test

[xedin]

@swift-ci please clean test

[xedin]

@swift-ci please clean test

[xedin]

@swift-ci please clean test Linux platform

[xedin]

@swift-ci please test macOS platform

[xedin]

@swift-ci please test Windows platform

[xedin]

@swift-ci please test

[xedin]

@swift-ci please test macOS platform

[xedin]

@swift-ci please test