jckarter/property-behavior-decl.md Secret

## 1,385 changes: 1,385 additions & 0 deletions property-behavior-decl.md
@@ -0,0 +1,1385 @@

    # Property Behaviors
# Property Behaviors


    * Proposal: [SE-NNNN](https://github.com/apple/swift-evolution/proposals/NNNN-name.md)
* Proposal: [SE-NNNN](https://github.com/apple/swift-evolution/proposals/NNNN-name.md)

    * Author(s): [Joe Groff](https://github.com/jckarter)
* Author(s): [Joe Groff](https://github.com/jckarter)

    * Status: **Review**
* Status: **Review**

    * Review manager: TBD
* Review manager: TBD


    ## Introduction
## Introduction


    There are property implementation patterns that come up repeatedly.
There are property implementation patterns that come up repeatedly.

    Rather than hardcode a fixed set of patterns into the compiler,
Rather than hardcode a fixed set of patterns into the compiler,

    we should provide a general "property behavior" mechanism to allow
we should provide a general "property behavior" mechanism to allow

    these patterns to be defined as libraries.
these patterns to be defined as libraries.


    ## Motivation
## Motivation


    We've tried to accommodate several important patterns for properties with
We've tried to accommodate several important patterns for properties with

    targeted language support, but this support has been narrow in scope and
targeted language support, but this support has been narrow in scope and

    utility.  For instance, Swift 1 and 2 provide `lazy` properties as a primitive
utility.  For instance, Swift 1 and 2 provide `lazy` properties as a primitive

    language feature, since lazy initialization is common and is often necessary to
language feature, since lazy initialization is common and is often necessary to

    avoid having properties be exposed as `Optional`. Without this language
avoid having properties be exposed as `Optional`. Without this language

    support, it takes a lot of boilerplate to get the same effect:
support, it takes a lot of boilerplate to get the same effect:


    ```swift
```swift

    class Foo {
class Foo {

      // lazy var foo = 1738
  // lazy var foo = 1738

      private var _foo: Int?
  private var _foo: Int?

      var foo: Int {
  var foo: Int {

        get {
    get {

          if let value = _foo { return value }
      if let value = _foo { return value }

          let initialValue = 1738
      let initialValue = 1738

          _foo = initialValue
      _foo = initialValue

          return initialValue
      return initialValue

        }
    }

        set {
    set {

          _foo = newValue
      _foo = newValue

        }
    }

      }
  }

    }
}

    ```
```


    Building `lazy` into the language has several disadvantages. It makes the
Building `lazy` into the language has several disadvantages. It makes the

    language and compiler more complex and less orthogonal. It's also inflexible;
language and compiler more complex and less orthogonal. It's also inflexible;

    there are many variations on lazy initialization that make sense, but we
there are many variations on lazy initialization that make sense, but we

    wouldn't want to hardcode language support for all of them. For instance, some
wouldn't want to hardcode language support for all of them. For instance, some

    applications may want the lazy initialization to be synchronized, but `lazy`
applications may want the lazy initialization to be synchronized, but `lazy`

    only provides single-threaded initialization. The standard implementation of
only provides single-threaded initialization. The standard implementation of

    `lazy` is also problematic for value types. A `lazy` getter must be `mutating`,
`lazy` is also problematic for value types. A `lazy` getter must be `mutating`,

    which means it can't be accessed from an immutable value.  Inline storage is
which means it can't be accessed from an immutable value.  Inline storage is

    also suboptimal for many memoization tasks, since the cache cannot be reused
also suboptimal for many memoization tasks, since the cache cannot be reused

    across copies of the value. A value-oriented memoized property implementation
across copies of the value. A value-oriented memoized property implementation

    might look very different, using a class instance to store the cached value
might look very different, using a class instance to store the cached value

    out-of-line in order to avoid mutation of the value itself. Lazy properties are
out-of-line in order to avoid mutation of the value itself. Lazy properties are

    also unable to surface any additional operations over a regular property, such
also unable to surface any additional operations over a regular property, such

    as to reset a lazy property's storage to be recomputed again.
as to reset a lazy property's storage to be recomputed again.


    There are important property patterns outside of lazy initialization.
There are important property patterns outside of lazy initialization.

    It often makes sense to have "delayed",
It often makes sense to have "delayed",

    once-assignable-then-immutable properties to support multi-phase initialization:
once-assignable-then-immutable properties to support multi-phase initialization:


    ```swift
```swift

    class Foo {
class Foo {

      let immediatelyInitialized = "foo"
  let immediatelyInitialized = "foo"

      var _initializedLater: String?
  var _initializedLater: String?


      // We want initializedLater to present like a non-optional 'let' to user code;
  // We want initializedLater to present like a non-optional 'let' to user code;

      // it can only be assigned once, and can't be accessed before being assigned.
  // it can only be assigned once, and can't be accessed before being assigned.

      var initializedLater: String {
  var initializedLater: String {

        get { return _initializedLater! }
    get { return _initializedLater! }

        set {
    set {

          assert(_initializedLater == nil)
      assert(_initializedLater == nil)

          _initializedLater = newValue
      _initializedLater = newValue

        }
    }

      }
  }

    }
}


    ```
```


    Implicitly-unwrapped optionals allow this in a pinch, but give up a lot of
Implicitly-unwrapped optionals allow this in a pinch, but give up a lot of

    safety compared to a non-optional 'let'. Using IUO for multi-phase initialization
safety compared to a non-optional 'let'. Using IUO for multi-phase initialization

    gives up both immutability and nil-safety.
gives up both immutability and nil-safety.


    We also have other application-specific property features like
We also have other application-specific property features like

    `didSet`/`willSet` and array addressors that add language complexity for
`didSet`/`willSet` and array addressors that add language complexity for

    limited functionality. Beyond what we've baked into the language already,
limited functionality. Beyond what we've baked into the language already,

    there's a seemingly endless set of common property behaviors, including
there's a seemingly endless set of common property behaviors, including

    resetting, synchronized access, and various kinds of proxying, all begging for
resetting, synchronized access, and various kinds of proxying, all begging for

    language attention to eliminate their boilerplate.
language attention to eliminate their boilerplate.


    ## Proposed solution
## Proposed solution


    I suggest we allow for **property behaviors** to be implemented within the
I suggest we allow for **property behaviors** to be implemented within the

    language.  A `var` or `let` declaration can specify its **behaviors** in square
language.  A `var` or `let` declaration can specify its **behaviors** in square

    brackets after the keyword:
brackets after the keyword:


    ```swift
```swift

    var [lazy] foo = 1738
var [lazy] foo = 1738

    ```
```


    which implements the property `foo` in a way described by the **property
which implements the property `foo` in a way described by the **property

    behavior declaration** for `lazy`:
behavior declaration** for `lazy`:


    ```swift
```swift

    var behavior lazy<Value>: Value {
var behavior lazy<Value>: Value {

      var value: Value? = nil
  var value: Value? = nil

      deferred initializer: Value
  deferred initializer: Value

      get {
  get {

        if let value = value {
    if let value = value {

          return value
      return value

        }
    }

        let initialValue = initializer
    let initialValue = initializer

        value = initialValue
    value = initialValue

        return initialValue
    return initialValue

      }
  }

      set {
  set {

        value = newValue
    value = newValue

      }
  }

    }
}

    ```
```


    Property behaviors can control the storage,
Property behaviors can control the storage,

    initialization, and access of affected properties, obviating the need for
initialization, and access of affected properties, obviating the need for

    special language support for `lazy`, observers, addressors, and other
special language support for `lazy`, observers, addressors, and other

    special-case property features. Property behaviors can also provide additional
special-case property features. Property behaviors can also provide additional

    operations on properties, such as `clear`-ing a lazy property, accessed with
operations on properties, such as `clear`-ing a lazy property, accessed with

    `property.behavior` syntax:
`property.behavior` syntax:


    ```swift
```swift

    extension lazy {
extension lazy {

      mutating func clear() {
  mutating func clear() {

        value = nil
    value = nil

      }
  }

    }
}


    foo.lazy.clear()
foo.lazy.clear()

    ```
```


    ## Examples
## Examples


    Before describing the detailed design, I'll run through some examples of
Before describing the detailed design, I'll run through some examples of

    potential applications for behaviors.
potential applications for behaviors.


    ### Lazy
### Lazy


    The current `lazy` property feature can be reimplemented as a property behavior.
The current `lazy` property feature can be reimplemented as a property behavior.


    ```swift
```swift

    // Property behaviors are declared using the `var behavior` keyword cluster.
// Property behaviors are declared using the `var behavior` keyword cluster.

    public var behavior lazy<Value>: Value {
public var behavior lazy<Value>: Value {

      // Behaviors can declare storage that backs the property.
  // Behaviors can declare storage that backs the property.

      private var value: Value?
  private var value: Value?


      // Behaviors can declare that properties using the behavior require
  // Behaviors can declare that properties using the behavior require

      // a `deferred initializer` expression. When deferred, the
  // a `deferred initializer` expression. When deferred, the

      // initializer expression is assumed to be evaluated after
  // initializer expression is assumed to be evaluated after

      // initialization of the containing value, which allows it to refer
  // initialization of the containing value, which allows it to refer

      // to `self`. If declared, `initializer` is bound in accessors and
  // to `self`. If declared, `initializer` is bound in accessors and

      // methods of the behavior.
  // methods of the behavior.

      deferred initializer: Value
  deferred initializer: Value


      // Behaviors can declare initialization logic for the storage.
  // Behaviors can declare initialization logic for the storage.

      // (Stored properties can also be initialized in-line.)
  // (Stored properties can also be initialized in-line.)

      init() {
  init() {

        value = nil
    value = nil

      }
  }


      // Inline initializers should also be supported, so `var value: Value? = nil`
  // Inline initializers should also be supported, so `var value: Value? = nil`

      // would work.
  // would work.


      // Behaviors can declare accessors that implement the property.
  // Behaviors can declare accessors that implement the property.

      get {
  get {

        if let value = value {
    if let value = value {

          return value
      return value

        }
    }

        //
    //

        value = initializer
    value = initializer

      }
  }

      set {
  set {

        value = newValue
    value = newValue

      }
  }


      // Behaviors can also declare methods to attach to the property.
  // Behaviors can also declare methods to attach to the property.

      public mutating func clear() {
  public mutating func clear() {

        value = nil
    value = nil

      }
  }

    }
}

    ```
```


    Properties declared with the `lazy` behavior are backed by the `Optional`-typed
Properties declared with the `lazy` behavior are backed by the `Optional`-typed

    storage and accessors from the behavior:
storage and accessors from the behavior:


    ```swift
```swift

    var [lazy] x = 1738 // Allocates an Int? behind the scenes, inited to nil
var [lazy] x = 1738 // Allocates an Int? behind the scenes, inited to nil

    print(x) // Invokes the `lazy` getter, initializing the property
print(x) // Invokes the `lazy` getter, initializing the property

    x = 679 // Invokes the `lazy` setter
x = 679 // Invokes the `lazy` setter

    ```
```


    Visible members of the behavior can also be accessed under `property.behavior`:
Visible members of the behavior can also be accessed under `property.behavior`:


    ```swift
```swift

    x.lazy.clear() // Invokes `lazy`'s `clear` method
x.lazy.clear() // Invokes `lazy`'s `clear` method

    ```
```


    ### Memoization
### Memoization


    Variations of `lazy` can be implemented that are more appropriate for certain
Variations of `lazy` can be implemented that are more appropriate for certain

    situations. For instance, here's a `memoized` behavior that stores the cached
situations. For instance, here's a `memoized` behavior that stores the cached

    value indirectly, making it suitable for immutable value types:
value indirectly, making it suitable for immutable value types:


    ```swift
```swift

    public var behavior memoized<Value>: Value {
public var behavior memoized<Value>: Value {

      public class MemoizationBox<Value> {
  public class MemoizationBox<Value> {

        var value: Value? = nil
    var value: Value? = nil

        public func getOrEvaluate(fn: () -> Value) -> Value {
    public func getOrEvaluate(fn: () -> Value) -> Value {

          if let value = value { return value }
      if let value = value { return value }

          // Perform the initialization in a thread-safe way.
      // Perform the initialization in a thread-safe way.

          // Implementation of 'sync' not shown here.
      // Implementation of 'sync' not shown here.

          return sync {
      return sync {

            let initialValue = fn()
        let initialValue = fn()

            value = initialValue
        value = initialValue

            return initialValue
        return initialValue

          }
      }

        }
    }

        func clear() {
    func clear() {

          value = nil
      value = nil

        }
    }

      }
  }


      let storage: MemoizationBox<Value> = MemoizationBox()
  let storage: MemoizationBox<Value> = MemoizationBox()


      deferred initializer: Value
  deferred initializer: Value


      get {
  get {

        return storage.getOrEvaluate { initializer }
    return storage.getOrEvaluate { initializer }

      }
  }


      public func clear() {
  public func clear() {

        storage.clear()
    storage.clear()

      }
  }

    }
}

    ```
```


    which can then be used like this:
which can then be used like this:


    ```swift
```swift

    struct Location {
struct Location {

      let street, city, postalCode: String
  let street, city, postalCode: String


      let [memoized] address = "\(street)\n\(city) \(postalCode)"
  let [memoized] address = "\(street)\n\(city) \(postalCode)"

    }
}

    ```
```


    ### Delayed Initialization
### Delayed Initialization


    A property behavior can model "delayed" initialization behavior, where the DI
A property behavior can model "delayed" initialization behavior, where the DI

    rules for properties are enforced dynamically rather than at compile time.
rules for properties are enforced dynamically rather than at compile time.

    This can avoid the need for implicitly-unwrapped optionals in multi-phase
This can avoid the need for implicitly-unwrapped optionals in multi-phase

    initialization use cases. We can implement both a mutable variant, which
initialization use cases. We can implement both a mutable variant, which

    allows for reassignment like a `var`:
allows for reassignment like a `var`:


    ```swift
```swift

    public var behavior delayedMutable<Value>: Value {
public var behavior delayedMutable<Value>: Value {

      private var value: Value? = nil
  private var value: Value? = nil


      get {
  get {

        guard let value = value else {
    guard let value = value else {

          fatalError("property accessed before being initialized")
      fatalError("property accessed before being initialized")

        }
    }

        return value
    return value

      }
  }

      set {
  set {

        value = newValue
    value = newValue

      }
  }


      // Perform an explicit initialization, trapping if the
  // Perform an explicit initialization, trapping if the

      // value is already initialized.
  // value is already initialized.

      public mutating func initialize(initialValue: Value) {
  public mutating func initialize(initialValue: Value) {

        if let _ = value {
    if let _ = value {

          fatalError("property initialized twice")
      fatalError("property initialized twice")

        }
    }

        value = initialValue
    value = initialValue

      }
  }

    }
}

    ```
```


    and an immutable variant, which only allows a single initialization like
and an immutable variant, which only allows a single initialization like

    a `let`:
a `let`:


    ```swift
```swift

    public var behavior delayedImmutable<Value>: Value {
public var behavior delayedImmutable<Value>: Value {

      private var value: Value? = nil
  private var value: Value? = nil


      get {
  get {

        guard let value = value else {
    guard let value = value else {

          fatalError("property accessed before being initialized")
      fatalError("property accessed before being initialized")

        }
    }

        return value
    return value

      }
  }


      // Perform an explicit initialization, trapping if the
  // Perform an explicit initialization, trapping if the

      // value is already initialized.
  // value is already initialized.

      public mutating func initialize(initialValue: Value) {
  public mutating func initialize(initialValue: Value) {

        if let _ = value {
    if let _ = value {

          fatalError("property initialized twice")
      fatalError("property initialized twice")

        }
    }

        value = initialValue
    value = initialValue

      }
  }

    }
}

    ```
```


    This enables multi-phase initialization, like this:
This enables multi-phase initialization, like this:


    ```swift
```swift

    class Foo {
class Foo {

      var [delayedImmutable] x: Int
  var [delayedImmutable] x: Int


      init() {
  init() {

        // We don't know "x" yet, and we don't have to set it
    // We don't know "x" yet, and we don't have to set it

      }
  }


      func initializeX(x: Int) {
  func initializeX(x: Int) {

        self.x.delayedImmutable.initialize(x) // Will crash if 'self.x' is already initialized
    self.x.delayedImmutable.initialize(x) // Will crash if 'self.x' is already initialized

      }
  }


      func getX() -> Int {
  func getX() -> Int {

        return x // Will crash if 'self.x' wasn't initialized
    return x // Will crash if 'self.x' wasn't initialized

      }
  }

    }
}

    ```
```


    #### Resettable properties
#### Resettable properties


    There's a common pattern in Cocoa where properties are used as optional
There's a common pattern in Cocoa where properties are used as optional

    customization points, but can be reset to nil to fall back to a non-public
customization points, but can be reset to nil to fall back to a non-public

    default value. In Swift, properties that follow this pattern currently must be
default value. In Swift, properties that follow this pattern currently must be

    imported as ImplicitlyUnwrappedOptional, even though the property can only be
imported as ImplicitlyUnwrappedOptional, even though the property can only be

    *set* to nil. If expressed as a behavior, the `reset` operation can be
*set* to nil. If expressed as a behavior, the `reset` operation can be

    decoupled from the type, allowing the property to be exported as non-optional:
decoupled from the type, allowing the property to be exported as non-optional:


    ```swift
```swift

    public var behavior resettable<Value>: Value {
public var behavior resettable<Value>: Value {

      // A behavior can declare an *eager* initializer, which is available
  // A behavior can declare an *eager* initializer, which is available

      // during initialization of the property, but which cannot refer to
  // during initialization of the property, but which cannot refer to

      // `self`.
  // `self`.

      eager initializer: Value
  eager initializer: Value


      var value: Value = initializer
  var value: Value = initializer


      get {
  get {

        return value
    return value

      }
  }

      set {
  set {

        value = newValue
    value = newValue

      }
  }


      // Reset the property to its original initialized value.
  // Reset the property to its original initialized value.

      mutating func reset() {
  mutating func reset() {

        value = initializer
    value = initializer

      }
  }

    }
}

    ```
```


    For example:
For example:


    ```
```

    var [resettable] foo: Int = 22
var [resettable] foo: Int = 22

    print(foo) // => 22
print(foo) // => 22

    foo = 44
foo = 44

    print(foo) // => 44
print(foo) // => 44

    foo.resettable.reset()
foo.resettable.reset()

    print(foo) // => 22
print(foo) // => 22

    ```
```


    ### Property Observers
### Property Observers


    A property behavior can also replicate the built-in behavior of `didSet`/`willSet`
A property behavior can also replicate the built-in behavior of `didSet`/`willSet`

    observers, by declaring support for custom accessors:
observers, by declaring support for custom accessors:


    ```swift
```swift

    public var behavior observed<Value>: Value {
public var behavior observed<Value>: Value {

      // For composability, a behavior can declare a `base` property. The
  // For composability, a behavior can declare a `base` property. The

      // base can be inherited from another behavior or an overridden
  // base can be inherited from another behavior or an overridden

      // superclass property; if neither of those are provided, a fresh stored
  // superclass property; if neither of those are provided, a fresh stored

      // property is generated in the containing scope.
  // property is generated in the containing scope.

      base var value: Value
  base var value: Value


      // A behavior can also declare accessors, the implementations of which
  // A behavior can also declare accessors, the implementations of which

      // must be provided by property declarations using the behavior.
  // must be provided by property declarations using the behavior.

      // The behavior may provide a default implementation of
  // The behavior may provide a default implementation of

      // the accessors, in order to make them optional.
  // the accessors, in order to make them optional.


      // The willSet accessor, invoked before the property is updated. The
  // The willSet accessor, invoked before the property is updated. The

      // default does nothing.
  // default does nothing.

      accessor willSet(newValue: Value) { }
  accessor willSet(newValue: Value) { }


      // The didSet accessor, invoked before the property is updated. The
  // The didSet accessor, invoked before the property is updated. The

      // default does nothing.
  // default does nothing.

      accessor didSet(oldValue: Value) { }
  accessor didSet(oldValue: Value) { }


      get {
  get {

        return value
    return value

      }
  }


      set {
  set {

        willSet(newValue)
    willSet(newValue)

        let oldValue = value
    let oldValue = value

        value = newValue
    value = newValue

        didSet(oldValue)
    didSet(oldValue)

      }
  }

    }
}

    ```
```


    Because the `observed` behavior declares a **base property**, it can also
Because the `observed` behavior declares a **base property**, it can also

    be composed on top of other behaviors:
be composed on top of other behaviors:


    ```swift
```swift

    var [lazy, observed] observedLazy = expensiveExpression() {
var [lazy, observed] observedLazy = expensiveExpression() {

      didSet { print("\(oldValue) => \(observedLazy)") }
  didSet { print("\(oldValue) => \(observedLazy)") }

    }
}

    ```
```


    or applied in subclasses that override base class properties, like `didSet`
or applied in subclasses that override base class properties, like `didSet`

    /`willSet` today:
/`willSet` today:


    ```swift
```swift

    class Foo {
class Foo {

      var foo: Int
  var foo: Int

    }
}


    class NoisyFoo: Foo {
class NoisyFoo: Foo {

      override var [observed] foo: Int {
  override var [observed] foo: Int {

        didSet { print("\(oldValue) => \(foo)") }
    didSet { print("\(oldValue) => \(foo)") }

      }
  }

    }
}

    ```
```


    A common complaint with `didSet`/`willSet` is that the observers fire on
A common complaint with `didSet`/`willSet` is that the observers fire on

    *every* write, not only ones that cause a real change. A behavior
*every* write, not only ones that cause a real change. A behavior

    that supports a `didChange` accessor, which only gets invoked if the property
that supports a `didChange` accessor, which only gets invoked if the property

    value really changed to a value not equal to the old value, can be implemented
value really changed to a value not equal to the old value, can be implemented

    as a new behavior:
as a new behavior:


    ```swift
```swift

    public var behavior changeObserved<Value: Equatable>: Value {
public var behavior changeObserved<Value: Equatable>: Value {

      base var value: Value
  base var value: Value


      mutating accessor didChange(oldValue: Value) { }
  mutating accessor didChange(oldValue: Value) { }


      get {
  get {

        return value
    return value

      }
  }

      set {
  set {

        let oldValue = value
    let oldValue = value

        value = newValue
    value = newValue

        if oldValue != newValue {
    if oldValue != newValue {

          didChange(oldValue)
      didChange(oldValue)

        }
    }

      }
  }

    }
}

    ```
```


    For example:
For example:


    ```swift
```swift

    var [changeObserved] x = 1 {
var [changeObserved] x = 1 {

      didChange { print("\(oldValue) => \(x)") }
  didChange { print("\(oldValue) => \(x)") }

    }
}


    x = 1 // Prints nothing
x = 1 // Prints nothing

    x = 2 // Prints 1 => 2
x = 2 // Prints 1 => 2

    ```
```


    ### Synchronized Property Access
### Synchronized Property Access


    Objective-C supports `atomic` properties, which take a lock on `get` and `set`
Objective-C supports `atomic` properties, which take a lock on `get` and `set`

    to synchronize accesses to a property. This is occasionally useful, and it can
to synchronize accesses to a property. This is occasionally useful, and it can

    be brought to Swift as a behavior. The real implementation of `atomic`
be brought to Swift as a behavior. The real implementation of `atomic`

    properties in ObjC uses a global bank of locks, but for illustrative purposes
properties in ObjC uses a global bank of locks, but for illustrative purposes

    (and to demonstrate referring to `self`) I'll use a per-object lock instead:
(and to demonstrate referring to `self`) I'll use a per-object lock instead:


    ```swift
```swift

    // A class that owns a mutex that can be used to synchronize access to its
// A class that owns a mutex that can be used to synchronize access to its

    // properties.
// properties.

    public protocol Synchronizable: class {
public protocol Synchronizable: class {

      func withLock<R>(@noescape body: () -> R) -> R
  func withLock<R>(@noescape body: () -> R) -> R

    }
}


    // Behaviors can refer to a property's containing type using
// Behaviors can refer to a property's containing type using

    // `Self` (including to impose constraints on it).
// `Self` (including to impose constraints on it).

    public var behavior synchronized<Value where Self: Synchronizable>: Value {
public var behavior synchronized<Value where Self: Synchronizable>: Value {

      base var value: Value
  base var value: Value


      get {
  get {

        return self.withLock {
    return self.withLock {

          return value
      return value

        }
    }

      }
  }

      set {
  set {

        self.withLock {
    self.withLock {

          value = newValue
      value = newValue

        }
    }

      }
  }

    }
}

    ```
```


    For example:
For example:


    ```swift
```swift

    // `Synchronizable` conformances not presented here
// `Synchronizable` conformances not presented here

    class SharedState: Synchronizable {
class SharedState: Synchronizable {

      var [synchronized] attributes: [String: Any] = [:]
  var [synchronized] attributes: [String: Any] = [:]

    }
}


    class LazySharedState: Synchronizable {
class LazySharedState: Synchronizable {

      var [lazy, synchronized] attributes: [String: Any]
  var [lazy, synchronized] attributes: [String: Any]

        = loadStateFromDisk()
    = loadStateFromDisk()

    }
}


    class State: NSObject {
class State: NSObject {

      var attributes: [String: Any]
  var attributes: [String: Any]

    }
}


    class SynchronizedState: State, Synchronizable {
class SynchronizedState: State, Synchronizable {

      override var [synchronized] attributes: [String: Any]
  override var [synchronized] attributes: [String: Any]

    }
}

    ```
```


    ### `NSCopying`
### `NSCopying`


    Many Cocoa classes implement value-like objects that require explicit copying.
Many Cocoa classes implement value-like objects that require explicit copying.

    Swift currently provides an `@NSCopying` attribute for properties to give
Swift currently provides an `@NSCopying` attribute for properties to give

    them behavior like Objective-C's `@property(copy)`, invoking the `copy` method
them behavior like Objective-C's `@property(copy)`, invoking the `copy` method

    on new objects when the property is set. We can turn this into a behavior:
on new objects when the property is set. We can turn this into a behavior:


    ```swift
```swift

    public var behavior copying<Value: NSCopying>: Value {
public var behavior copying<Value: NSCopying>: Value {

      base var value: Value
  base var value: Value


      get {
  get {

        return value
    return value

      }
  }

      set {
  set {

        // Copy the value on reassignment.
    // Copy the value on reassignment.

        value = newValue.copy()
    value = newValue.copy()

      }
  }

    }
}

    ```
```


    This is a small sampling of the possibilities of behaviors. Let's look at the
This is a small sampling of the possibilities of behaviors. Let's look at the

    proposed design in detail:
proposed design in detail:


    ## Detailed design
## Detailed design


    ### Property behavior declarations
### Property behavior declarations


    A **property behavior declaration** is introduced by the `var behavior`
A **property behavior declaration** is introduced by the `var behavior`

    contextual keyword cluster, which declares the (possibly generic) type of
contextual keyword cluster, which declares the (possibly generic) type of

    properties supported by the behavior.
properties supported by the behavior.


    ```text
```text

    property-behavior-decl ::=
property-behavior-decl ::=

      attribute* decl-modifier*
  attribute* decl-modifier*

      'var' 'behavior' identifier generic-param-list? ':' type '{'
  'var' 'behavior' identifier generic-param-list? ':' type '{'

        property-behavior-member-decl*
    property-behavior-member-decl*

      '}'
  '}'

    ```
```


    Inside the behavior declaration, standard initializer, property, method, and
Inside the behavior declaration, standard initializer, property, method, and

    nested type declarations are allowed, as are **core accessor** declarations
nested type declarations are allowed, as are **core accessor** declarations

    —`get` and `set`. Additional contextual declarations are
—`get` and `set`. Additional contextual declarations are

    supported for **initializer requirement declarations**,
supported for **initializer requirement declarations**,

    **base property declarations**, and
**base property declarations**, and

    **accessor requirement declarations**:
**accessor requirement declarations**:


    ```text
```text

    property-behavior-member-decl ::= decl
property-behavior-member-decl ::= decl

    property-behavior-member-decl ::= core-accessor-decl // get, set
property-behavior-member-decl ::= core-accessor-decl // get, set

    property-behavior-member-decl ::= property-behavior-initializer-decl
property-behavior-member-decl ::= property-behavior-initializer-decl

    property-behavior-member-decl ::= property-behavior-base-property-decl
property-behavior-member-decl ::= property-behavior-base-property-decl

    property-behavior-member-decl ::= property-behavior-accessor-decl // accessor foo(...)
property-behavior-member-decl ::= property-behavior-accessor-decl // accessor foo(...)

    ```
```


    ### Bindings within Behavior Declarations
### Bindings within Behavior Declarations


    Definitions within behaviors can refer to other members of the behavior by
Definitions within behaviors can refer to other members of the behavior by

    unqualified lookup, or if disambiguation is necessary, by qualified lookup
unqualified lookup, or if disambiguation is necessary, by qualified lookup

    on the behavior:
on the behavior:


    ```swift
```swift

    var behavior foo: Int {
var behavior foo: Int {

      var x: Int
  var x: Int


      init() {
  init() {

        x = 1738
    x = 1738

      }
  }


      mutating func update(x: Int) {
  mutating func update(x: Int) {

        foo.x = x // Disambiguate reference to behavior storage
    foo.x = x // Disambiguate reference to behavior storage

      }
  }

    }
}

    ```
```


    If the behavior includes an *initializer requirement declaration*, then
If the behavior includes an *initializer requirement declaration*, then

    `initializer` is bound as a computed get-only property that evaluates the
`initializer` is bound as a computed get-only property that evaluates the

    property's initializer expression:
property's initializer expression:


    ```swift
```swift

    var behavior foo<Value>: Value {
var behavior foo<Value>: Value {

      deferred initializer: Value
  deferred initializer: Value


      get {
  get {

        return initializer
    return initializer

      }
  }

    }
}

    ```
```


    If the behavior includes *accessor requirement declarations*, then the
If the behavior includes *accessor requirement declarations*, then the

    declared accessor names are bound as functions with labeled arguments:
declared accessor names are bound as functions with labeled arguments:


    ```swift
```swift

    var behavior fakeComputed<Value>: Value {
var behavior fakeComputed<Value>: Value {

      accessor get() -> Value
  accessor get() -> Value

      mutating accessor set(newValue: Value)
  mutating accessor set(newValue: Value)


      get {
  get {

        return get()
    return get()

      }
  }

      set {
  set {

        set(newValue: newValue)
    set(newValue: newValue)

      }
  }

    }
}

    ```
```


    Note that the behavior's own *core accessor* implementations are *not*
Note that the behavior's own *core accessor* implementations are *not*

    referenceable this way.
referenceable this way.


    Inside a behavior declaration, `self` is implicitly bound to the value that
Inside a behavior declaration, `self` is implicitly bound to the value that

    contains the property instantiated using this behavior. For a freestanding
contains the property instantiated using this behavior. For a freestanding

    property at global or local scope, this will be the empty tuple `()`, and
property at global or local scope, this will be the empty tuple `()`, and

    for a static or class property, this will be the metatype. Within
for a static or class property, this will be the metatype. Within

    the behavior declaration, the type of `self` is abstract and represented by the
the behavior declaration, the type of `self` is abstract and represented by the

    implicit generic type parameter `Self`. Constraints can be placed on `Self`
implicit generic type parameter `Self`. Constraints can be placed on `Self`

    in the generic signature of the behavior, to make protocol members available
in the generic signature of the behavior, to make protocol members available

    on `self`:
on `self`:


    ```swift
```swift

    protocol Fungible {
protocol Fungible {

      typealias Fungus
  typealias Fungus

      func funge() -> Fungus
  func funge() -> Fungus

    }
}


    var behavior runcible<Value where Self: Fungible, Self.Fungus == Value>: Value {
var behavior runcible<Value where Self: Fungible, Self.Fungus == Value>: Value {

      get {
  get {

        return self.funge()
    return self.funge()

      }
  }

    }
}

    ```
```


    Lookup within `self` is *not* implicit within behaviors and must always be
Lookup within `self` is *not* implicit within behaviors and must always be

    explicit, since unqualified lookup refers to the behavior's own members. `self`
explicit, since unqualified lookup refers to the behavior's own members. `self`

    is immutable except in `mutating` methods, where it is considered an `inout`
is immutable except in `mutating` methods, where it is considered an `inout`

    parameter unless the `Self` type has a class constraint.  `self` cannot be
parameter unless the `Self` type has a class constraint.  `self` cannot be

    accessed within inline initializers of the behavior's storage or in `init`
accessed within inline initializers of the behavior's storage or in `init`

    declarations, since these may run during the container's own initialization
declarations, since these may run during the container's own initialization

    phase.
phase.


    ### Nested Types in Behaviors
### Nested Types in Behaviors


    Behavior declarations may nest type declarations as a namespacing mechanism.
Behavior declarations may nest type declarations as a namespacing mechanism.

    As with other type declarations, the nested type cannot reference members
As with other type declarations, the nested type cannot reference members

    from its enclosing behavior.
from its enclosing behavior.


    ### Properties and Methods in Behaviors
### Properties and Methods in Behaviors


    Behaviors may include property and method declarations. Any storage produced
Behaviors may include property and method declarations. Any storage produced

    by behavior properties is expanded into the containing scope of a property
by behavior properties is expanded into the containing scope of a property

    using the behavior.
using the behavior.


    ```swift
```swift

    var behavior runcible: Int {
var behavior runcible: Int {

      var x: Int = 0
  var x: Int = 0

      let y: String = ""
  let y: String = ""

    }
}

    var [runcible] a: Int
var [runcible] a: Int


    // expands to:
// expands to:


    var `a.runcible.x`: Int
var `a.runcible.x`: Int

    let `a.runcible.y`: String
let `a.runcible.y`: String

    var a: Int { ... }
var a: Int { ... }

    ```
```


    For public behaviors, this is inherently *fragile*, so
For public behaviors, this is inherently *fragile*, so

    adding or removing storage is a breaking change. Resilience can be achieved
adding or removing storage is a breaking change. Resilience can be achieved

    by using a resilient type as storage. The instantiated properties must also
by using a resilient type as storage. The instantiated properties must also

    be of types that are visible to potential users of the behavior, meaning
be of types that are visible to potential users of the behavior, meaning

    that public behaviors must use storage with types that are either public
that public behaviors must use storage with types that are either public

    or internal-with-availability, similar to the restrictions on inlineable
or internal-with-availability, similar to the restrictions on inlineable

    functions.
functions.


    The properties and methods of the
The properties and methods of the

    behavior are accessible from properties using the behavior, if they
behavior are accessible from properties using the behavior, if they

    have sufficient visibility.
have sufficient visibility.


    ```swift
```swift

    var behavior runcible: Int {
var behavior runcible: Int {

      private var x: Int = 0
  private var x: Int = 0

      var y: String = ""
  var y: String = ""


      func foo() {}
  func foo() {}

    }
}


    // In a different file...
// In a different file...


    var [runcible] a: Int
var [runcible] a: Int

    _ = a.runcible.x // Error, runcible.x is private
_ = a.runcible.x // Error, runcible.x is private

    _ = a.runcible.y // OK
_ = a.runcible.y // OK

    a.runcible.foo() // OK
a.runcible.foo() // OK

    ```
```


    Method and computed property implementations have only immutable access to
Method and computed property implementations have only immutable access to

    `self` and their storage by default, unless they are `mutating`. (As with
`self` and their storage by default, unless they are `mutating`. (As with

    computed properties, setters are `mutating` by default unless explicitly
computed properties, setters are `mutating` by default unless explicitly

    marked `nonmutating`).
marked `nonmutating`).


    ### Base Property
### Base Property


    A behavior may declare no more than one **base property**, which can be
A behavior may declare no more than one **base property**, which can be

    used to compose and override with behaviors. A base property is declared
used to compose and override with behaviors. A base property is declared

    using the contextual `base` modifier on a `var` or `let` declaration:
using the contextual `base` modifier on a `var` or `let` declaration:


    ```text
```text

    property-behavior-base-property-decl ::=
property-behavior-base-property-decl ::=

      attribute* (decl-modifier | 'base')* core-property-decl
  attribute* (decl-modifier | 'base')* core-property-decl


    // core-property-decl refers to the existing property-decl syntax without
// core-property-decl refers to the existing property-decl syntax without

    // `attribute* decl-modifier*` prefix
// `attribute* decl-modifier*` prefix

    ```
```


    The base property must have the
The base property must have the

    same type as the behavior. When a behavior declares a base property, a property
same type as the behavior. When a behavior declares a base property, a property

    using the behavior by itself instantiates the base property as a stored
using the behavior by itself instantiates the base property as a stored

    property, passing through any initialization:
property, passing through any initialization:


    ```swift
```swift

    var behavior hasBase: Int {
var behavior hasBase: Int {

      base var value: Int
  base var value: Int

    }
}


    var [hasBase] x: Int = 0 // `x.hasBase.base` instantiated as stored property
var [hasBase] x: Int = 0 // `x.hasBase.base` instantiated as stored property

    var [hasBase] y: Int // `y.hasBase.base` instantiated as stored property
var [hasBase] y: Int // `y.hasBase.base` instantiated as stored property

    y = 0 // Late initialization of `y`
y = 0 // Late initialization of `y`

    ```
```


    A property may use multiple behaviors, if all behaviors after the first
A property may use multiple behaviors, if all behaviors after the first

    use a base property. Each behavior sees the result of the previous behavior
use a base property. Each behavior sees the result of the previous behavior

    as its base.
as its base.


    ```swift
```swift

    var behavior root: Int { ... }
var behavior root: Int { ... }


    var [root, hasBase] z: Int
var [root, hasBase] z: Int

    // Instantiates:
// Instantiates:

    //   var [root] `z.hasBase.value`: Int
//   var [root] `z.hasBase.value`: Int

    // as the base for:
// as the base for:

    //   var [hasBase] z: Int
//   var [hasBase] z: Int

    ```
```


    If a subclass `override`-s a property, it may apply behaviors to the overridden
If a subclass `override`-s a property, it may apply behaviors to the overridden

    property, which will be used as its `base`.
property, which will be used as its `base`.


    ```
```

    class Foo {
class Foo {

      var x: Int = 0
  var x: Int = 0

    }
}

    class Bar: Foo {
class Bar: Foo {

      override var [hasBase] x: Int // uses `super.x` as `x.hasBase.value`
  override var [hasBase] x: Int // uses `super.x` as `x.hasBase.value`

    }
}

    ```
```


    Inside a behavior declaration, the base property declaration cannot have an
Inside a behavior declaration, the base property declaration cannot have an

    inline initializer or be initialized in an `init` declaration, since the
inline initializer or be initialized in an `init` declaration, since the

    underlying base property may not be owned by the behavior instantiation.
underlying base property may not be owned by the behavior instantiation.

    A base property declaration also may not appear with an initializer
A base property declaration also may not appear with an initializer

    requirement declaration.
requirement declaration.


    ### `init` in Behaviors
### `init` in Behaviors


    The storage of a behavior must be initialized, either by inline initialization,
The storage of a behavior must be initialized, either by inline initialization,

    or by an `init` declaration within the initializer:
or by an `init` declaration within the initializer:


    ```swift
```swift

    var behavior inlineInitialized: Int {
var behavior inlineInitialized: Int {

      var x: Int = 0 // initialized inline
  var x: Int = 0 // initialized inline

      get { return x }
  get { return x }

    }
}


    var behavior initInitialized: Int {
var behavior initInitialized: Int {

      var x: Int
  var x: Int

      get { return x }
  get { return x }


      init() {
  init() {

        x = 0
    x = 0

      }
  }

    }
}

    ```
```


    Behaviors can contain at most one `init` declaration, which must take no
Behaviors can contain at most one `init` declaration, which must take no

    parameters. This `init` declaration cannot take a visibility modifier; it
parameters. This `init` declaration cannot take a visibility modifier; it

    is always as visible as the behavior itself. Neither inline initializers nor
is always as visible as the behavior itself. Neither inline initializers nor

    `init` declaration bodies may reference `self`, since they will be executed
`init` declaration bodies may reference `self`, since they will be executed

    during the initializing of a property's containing value. For the same
during the initializing of a property's containing value. For the same

    reason, an `init` also may not refer to the `base` property, if any, nor
reason, an `init` also may not refer to the `base` property, if any, nor

    may it invoke any accessor requirements or deferred initializer requirements.
may it invoke any accessor requirements or deferred initializer requirements.


    ### Accessor Requirement Declarations
### Accessor Requirement Declarations


    An *accessor requirement declaration* specifies that a behavior requires
An *accessor requirement declaration* specifies that a behavior requires

    any property declared to use the behavior to provide an accessor
any property declared to use the behavior to provide an accessor

    implementation. An accessor requirement declaration is introduced by the
implementation. An accessor requirement declaration is introduced by the

    contextual `accessor` keyword:
contextual `accessor` keyword:


    ```swift
```swift

    property-behavior-accessor-decl ::=
property-behavior-accessor-decl ::=

      attribute* decl-modifier*
  attribute* decl-modifier*

      'accessor' identifier function-signature function-body?
  'accessor' identifier function-signature function-body?

    ```
```


    An accessor requirement declaration looks like, and serves a similar role to,
An accessor requirement declaration looks like, and serves a similar role to,

    a function requirement declaration in a protocol. A property using the
a function requirement declaration in a protocol. A property using the

    behavior must supply an implementation for each of its accessor requirements.
behavior must supply an implementation for each of its accessor requirements.

    The accessor names (with labeled arguments) are bound as functions within
The accessor names (with labeled arguments) are bound as functions within

    the behavior declaration:
the behavior declaration:


    ```swift
```swift

    // Reinvent computed properties
// Reinvent computed properties

    var behavior computed<Value>: Value {
var behavior computed<Value>: Value {

      accessor get() -> Value
  accessor get() -> Value

      mutating accessor set(newValue: Value)
  mutating accessor set(newValue: Value)


      get { return get() }
  get { return get() }

      set { set(newValue: newValue) }
  set { set(newValue: newValue) }

    }
}


    var [computed] foo: Int {
var [computed] foo: Int {

      get {
  get {

        return 0
    return 0

      }
  }

      set {
  set {

        // Parameter gets the name 'newValue' from the accessor requirement
    // Parameter gets the name 'newValue' from the accessor requirement

        // by default, as with built-in accessors today.
    // by default, as with built-in accessors today.

        print(newValue)
    print(newValue)

      }
  }

    }
}


    var [computed] bar: Int {
var [computed] bar: Int {

      get {
  get {

        return 0
    return 0

      }
  }

      set(myNewValue) {
  set(myNewValue) {

        // Parameter name can be overridden as well
    // Parameter name can be overridden as well

        print(myNewValue)
    print(myNewValue)

      }
  }

    }
}

    ```
```


    Accessor requirements can be made optional by specifying a default
Accessor requirements can be made optional by specifying a default

    implementation:
implementation:


    ```swift
```swift

    // Reinvent property observers
// Reinvent property observers

    var behavior observed<Value>: Value {
var behavior observed<Value>: Value {

      base var value: Value
  base var value: Value


      mutating accessor willSet(newValue: Value) {
  mutating accessor willSet(newValue: Value) {

        // do nothing by default
    // do nothing by default

      }
  }

      mutating accessor didSet(oldValue: Value) {
  mutating accessor didSet(oldValue: Value) {

        // do nothing by default
    // do nothing by default

      }
  }


      get {
  get {

        return value
    return value

      }
  }

      set {
  set {

        willSet(newValue: newValue)
    willSet(newValue: newValue)

        let oldValue = value
    let oldValue = value

        value = newValue
    value = newValue

        didSet(oldValue: oldValue)
    didSet(oldValue: oldValue)

      }
  }

    }
}

    ```
```


    Accessor requirements cannot take visibility modifiers; they are always as
Accessor requirements cannot take visibility modifiers; they are always as

    visible as the behavior itself.
visible as the behavior itself.


    Like methods, accessors are not allowed to mutate the storage of the behavior
Like methods, accessors are not allowed to mutate the storage of the behavior

    or `self` unless declared `mutating`. Mutating accessors can only be invoked
or `self` unless declared `mutating`. Mutating accessors can only be invoked

    by the behavior from other `mutating` contexts.
by the behavior from other `mutating` contexts.


    ### Initializer Requirement Declarations
### Initializer Requirement Declarations


    A behavior can require an inline initializer expression with an *initializer
A behavior can require an inline initializer expression with an *initializer

    requirement declaration*, specified by the contextual `initializer` keyword:
requirement declaration*, specified by the contextual `initializer` keyword:


    ```text
```text

    property-behavior-initializer-decl ::=
property-behavior-initializer-decl ::=

      ('eager' | 'deferred') 'initializer' ':' type
  ('eager' | 'deferred') 'initializer' ':' type

    ```
```


    The type of `initializer` must match the type of the behavior.
The type of `initializer` must match the type of the behavior.

    The initializer requirement must be declared as `eager` or `deferred`,
The initializer requirement must be declared as `eager` or `deferred`,

    indicating where in the initialization process the initializer expression
indicating where in the initialization process the initializer expression

    is used:
is used:


    - An **eager initializer** is used during the initialization of the behavior's
- An **eager initializer** is used during the initialization of the behavior's

      state. An eager initializer can be used in the `init` implementation of
  state. An eager initializer can be used in the `init` implementation of

      a behavior, or in the inline initializer of one or more of its instantiated
  a behavior, or in the inline initializer of one or more of its instantiated

      stored properties. A property using the behavior cannot refer to `self`
  stored properties. A property using the behavior cannot refer to `self`

      within its initializer expression, as in a normal stored property.
  within its initializer expression, as in a normal stored property.


        ```swift
    ```swift

        var behavior eagerInit: Int {
    var behavior eagerInit: Int {

          eager initializer: Int
      eager initializer: Int


          var value: Int
      var value: Int


          init() {
      init() {

            value = initializer // Allowed for eager initializer
        value = initializer // Allowed for eager initializer

          }
      }


          get {
      get {

            return value + initializer
        return value + initializer

          }
      }

        }
    }


        class Foo {
    class Foo {

          var [eagerInit] foo: Int = self.bar // Not allowed
      var [eagerInit] foo: Int = self.bar // Not allowed

          var bar: Int
      var bar: Int

        }
    }

        ```
    ```


    - A **deferred initializer** is used only after the initialization of the
- A **deferred initializer** is used only after the initialization of the

      behavior's state. A deferred initializer cannot be referenced until
  behavior's state. A deferred initializer cannot be referenced until

      the behavior's storage is initialized. A property using the behavior can
  the behavior's storage is initialized. A property using the behavior can

      refer to `self` within its initializer expression, as one would expect
  refer to `self` within its initializer expression, as one would expect

      a `lazy` property to be able to.
  a `lazy` property to be able to.


        ```swift
    ```swift

        var behavior deferredInit: Int {
    var behavior deferredInit: Int {

          eager initializer: Int
      eager initializer: Int


          var value: Int
      var value: Int


          init() {
      init() {

            value = initializer // Not allowed
        value = initializer // Not allowed

          }
      }


          get {
      get {

            return value + initializer
        return value + initializer

          }
      }

        }
    }


        class Foo {
    class Foo {

          var [deferredInit] foo: Int = self.bar // OK
      var [deferredInit] foo: Int = self.bar // OK

          var bar: Int
      var bar: Int

        }
    }

        ```
    ```


    When a behavior declares an initializer requirement, the name `initializer`
When a behavior declares an initializer requirement, the name `initializer`

    is bound within the behavior declaration as a computed get-only property that
is bound within the behavior declaration as a computed get-only property that

    evaluates the property's initializer expression. A property behavior with a
evaluates the property's initializer expression. A property behavior with a

    `base` property member cannot require an initializer. A property behavior
`base` property member cannot require an initializer. A property behavior

    with an initializer requirement also cannot be applied to a property
with an initializer requirement also cannot be applied to a property

    declaration with a destructuring pattern.
declaration with a destructuring pattern.


    ```swift
```swift

    var [deferredInit] (a, b) = tuple // Error
var [deferredInit] (a, b) = tuple // Error

    ```
```


    Initializer requirements do not take visibility modifiers; they are always
Initializer requirements do not take visibility modifiers; they are always

    as visible as the behavior.
as visible as the behavior.


    ### Core Accessor Declarations
### Core Accessor Declarations


    The behavior implements the property by defining its *core accessors*,
The behavior implements the property by defining its *core accessors*,

    `get` and optionally `set`. If a behavior only provides a getter, it
`get` and optionally `set`. If a behavior only provides a getter, it

    produces read-only properties; if it provides both a getter and setter, it
produces read-only properties; if it provides both a getter and setter, it

    produces mutable properties (though properties that instantiate the behavior
produces mutable properties (though properties that instantiate the behavior

    may still control the visibility of their setters). It is an error if
may still control the visibility of their setters). It is an error if

    a behavior declaration does not provide at least a getter.
a behavior declaration does not provide at least a getter.


    ### Using Behaviors in Property Declarations
### Using Behaviors in Property Declarations


    Property declarations gain the ability to declare behaviors,
Property declarations gain the ability to declare behaviors,

    with arbitrary accessors:
with arbitrary accessors:


    ```text
```text

    property-decl ::= attribute* decl-modifier* core-property-decl
property-decl ::= attribute* decl-modifier* core-property-decl

    core-property-decl ::=
core-property-decl ::=

      ('var' | 'let') behaviors? pattern-binding
  ('var' | 'let') behaviors? pattern-binding

      ((',' pattern-binding)+ | accessors)?
  ((',' pattern-binding)+ | accessors)?

    behaviors ::= '[' visibility? decl-ref (',' visibility? decl-ref)* ']'
behaviors ::= '[' visibility? decl-ref (',' visibility? decl-ref)* ']'

    pattern-binding ::= var-pattern (':' type)? inline-initializer?
pattern-binding ::= var-pattern (':' type)? inline-initializer?

    inline-initializer ::= '=' expr
inline-initializer ::= '=' expr

    accessors ::= '{' accessor+ '}' | brace-stmt // see notes about disambiguation
accessors ::= '{' accessor+ '}' | brace-stmt // see notes about disambiguation

    accessor ::= decl-modifier* decl-ref accessor-args? brace-stmt
accessor ::= decl-modifier* decl-ref accessor-args? brace-stmt

    accessor-args ::= '(' identifier (',' identifier)* ')'
accessor-args ::= '(' identifier (',' identifier)* ')'

    ```
```


    For example:
For example:


    ```swift
```swift

    public var [behavior1, public behavior2] prop: Int {
public var [behavior1, public behavior2] prop: Int {

      accessor1 { body() }
  accessor1 { body() }

      behavior1.accessor2(arg) { body() }
  behavior1.accessor2(arg) { body() }

      behavior2.accessor3 { body() }
  behavior2.accessor3 { body() }

    }
}

    ```
```


    If multiple properties are declared in the same declaration, the behaviors
If multiple properties are declared in the same declaration, the behaviors

    apply to every declared property. `let` properties cannot use behaviors
apply to every declared property. `let` properties cannot use behaviors

    in this proposal.
in this proposal.


    When a property is declared with behaviors, the behaviors are instantiated
When a property is declared with behaviors, the behaviors are instantiated

    left-to-right, with each instantiated property used as the base property of
left-to-right, with each instantiated property used as the base property of

    the next behavior instantiation. It is an error if any of the behaviors after
the next behavior instantiation. It is an error if any of the behaviors after

    the first don't declare a base property, or if the behavior cannot be
the first don't declare a base property, or if the behavior cannot be

    instantiated for the property's type or `self` type. If the behaviors require
instantiated for the property's type or `self` type. If the behaviors require

    accessors, the implementations for those accessors are taken from the
accessors, the implementations for those accessors are taken from the

    property's accessor declarations, matching by name. If two behaviors require
property's accessor declarations, matching by name. If two behaviors require

    accessors of the same name, the accessor definitions can disambiguate using
accessors of the same name, the accessor definitions can disambiguate using

    qualified names.  If an accessor requirement takes parameters, but the
qualified names.  If an accessor requirement takes parameters, but the

    definition in for the property does not explicitly name parameters, the
definition in for the property does not explicitly name parameters, the

    parameter labels from the behavior's accessor requirement declaration are
parameter labels from the behavior's accessor requirement declaration are

    implicitly bound by default.
implicitly bound by default.


    ```swift
```swift

    var behavior foo: Int {
var behavior foo: Int {

      accessor bar(arg: Int)
  accessor bar(arg: Int)

      get { return 0 }
  get { return 0 }

    }
}


    var [foo] x: Int {
var [foo] x: Int {

      bar { print(arg) } // `arg` implicitly bound
  bar { print(arg) } // `arg` implicitly bound

    }
}


    var [foo] x: Int {
var [foo] x: Int {

      bar(myArg) { print(myArg) } // `arg` explicitly bound to `myArg`
  bar(myArg) { print(myArg) } // `arg` explicitly bound to `myArg`

    }
}

    ```
```


    If any accessor definition in the property does not match up to a behavior
If any accessor definition in the property does not match up to a behavior

    requirement, it is an error.
requirement, it is an error.


    To preserve the shorthand for get-only computed properties, if the accessor
To preserve the shorthand for get-only computed properties, if the accessor

    declaration consists of code like a function body, that code is used as
declaration consists of code like a function body, that code is used as

    the implementation of a single accessor named `get`:
the implementation of a single accessor named `get`:


    ```swift
```swift

    var [foo] x: Int {
var [foo] x: Int {

      return 0
  return 0

    }
}


    // is sugar for:
// is sugar for:


    var [foo] x: Int {
var [foo] x: Int {

      get {
  get {

        return 0
    return 0

      }
  }

    }
}

    ```
```


    The parser resolves the ambiguity between implicit getter and named accessor
The parser resolves the ambiguity between implicit getter and named accessor

    syntax by reading ahead for `identifier ('.' identifier)* ('(' .* ')')  '{'`,
syntax by reading ahead for `identifier ('.' identifier)* ('(' .* ')')  '{'`,

    favoring parsing as a named accessor declaration if the lookahead succeeds.
favoring parsing as a named accessor declaration if the lookahead succeeds.


    If a property with behaviors declares an inline initializer, it behaves as
If a property with behaviors declares an inline initializer, it behaves as

    follows:
follows:


    - If the first behavior has an initializer requirement, the initializer
- If the first behavior has an initializer requirement, the initializer

      expression is bound as the initializer when instantiating the behavior.
  expression is bound as the initializer when instantiating the behavior.

      An initializer requirement in a behavior can only be satisfied if the
  An initializer requirement in a behavior can only be satisfied if the

      declaration is not destructuring.
  declaration is not destructuring.

    - If the first behavior declares a base property, and the base property is
- If the first behavior declares a base property, and the base property is

      not satisfied by `override`-ing a super property, then the initializer
  not satisfied by `override`-ing a super property, then the initializer

      expression is used to initialize the storage of the default stored base
  expression is used to initialize the storage of the default stored base

      property.
  property.

    - Otherwise, it is an error to provide an inline initializer.
- Otherwise, it is an error to provide an inline initializer.


    ```
```

    var behavior noInitializer: Int {
var behavior noInitializer: Int {

      get { return 0 }
  get { return 0 }

    }
}


    var behavior initializerReqt: Int {
var behavior initializerReqt: Int {

      deferred initializer: Int
  deferred initializer: Int

      get { return 0 }
  get { return 0 }

    }
}


    var behavior baseProp: Int {
var behavior baseProp: Int {

      base var value: Int
  base var value: Int

      get { return 0 }
  get { return 0 }

    }
}


    var [baseProp] x = 0 // OK, base property initialized to 0
var [baseProp] x = 0 // OK, base property initialized to 0

    var [initializerReqt] y = 0 // OK, satisfies initializer requirement
var [initializerReqt] y = 0 // OK, satisfies initializer requirement

    var [initializerReqt] (a, b) = tuple // Error, behavior can't destructure
var [initializerReqt] (a, b) = tuple // Error, behavior can't destructure

    var [noInitializer] z = 0 // Error, behavior doesn't support initializer
var [noInitializer] z = 0 // Error, behavior doesn't support initializer

    ```
```


    If a behavior instantiates a default stored base property, it may be an
If a behavior instantiates a default stored base property, it may be an

    error to leave out the initializer, if the property is not
error to leave out the initializer, if the property is not

    initialized before use.
initialized before use.


    ### Accessing Behavior Members on Properties
### Accessing Behavior Members on Properties


    A behavior's properties and methods can be accessed on properties using the
A behavior's properties and methods can be accessed on properties using the

    behavior under `property.behavior`:
behavior under `property.behavior`:


    ```swift
```swift

    var behavior foo: Int {
var behavior foo: Int {

      var storage: Int = 0
  var storage: Int = 0

      func method() { }
  func method() { }

      get { return storage }
  get { return storage }

    }
}


    var [foo] x: Int
var [foo] x: Int

    print(x.foo.storage)
print(x.foo.storage)

    x.foo.method()
x.foo.method()

    ```
```


    To access a behavior member, code must have visibility of both the property's
To access a behavior member, code must have visibility of both the property's

    behavior, and the behavior's member. Behaviors are `private` by default,
behavior, and the behavior's member. Behaviors are `private` by default,

    unless declared with a higher visibility. A behavior cannot be more visible
unless declared with a higher visibility. A behavior cannot be more visible

    than the property it applies to.
than the property it applies to.


    ```swift
```swift

    // foo.swift
// foo.swift

    var behavior foo: Int {
var behavior foo: Int {

      private var storage: Int = 0
  private var storage: Int = 0

      func method() { }
  func method() { }

      get { return storage }
  get { return storage }

    }
}


    // bar.swift
// bar.swift

    var [foo] bar: Int
var [foo] bar: Int

    var [internal foo] internalFoo: Int
var [internal foo] internalFoo: Int

    var [public foo] publicFoo: Int // Error, behavior more visible than property
var [public foo] publicFoo: Int // Error, behavior more visible than property


    _ = bar.foo.storage // Error, `storage` is private to behavior
_ = bar.foo.storage // Error, `storage` is private to behavior

    bar.foo.method() // OK
bar.foo.method() // OK


    // bas.swift
// bas.swift

    bar.foo.method() // Error, `foo` behavior is private
bar.foo.method() // Error, `foo` behavior is private

    internalFoo.foo.method() // OK
internalFoo.foo.method() // OK

    ```
```


    Methods, properties, and nested types within the behavior can be accessed.
Methods, properties, and nested types within the behavior can be accessed.

    It is not allowed to access a behavior's `init` declaration, initializer
It is not allowed to access a behavior's `init` declaration, initializer

    or accessor requirements, or core accessors from outside the behavior
or accessor requirements, or core accessors from outside the behavior

    declaration.
declaration.


    ### Extensions on Behaviors
### Extensions on Behaviors


    Property behaviors should support extensions, to allow new methods or computed
Property behaviors should support extensions, to allow new methods or computed

    properties to be added, or to provide categorization:
properties to be added, or to provide categorization:


    ```swift
```swift

    var behavior foo: Int {
var behavior foo: Int {

      base var value: Int
  base var value: Int

      get {
  get {

        return value
    return value

      }
  }

    }
}


    extension foo {
extension foo {

      mutating func inc() {
  mutating func inc() {

        value += 1
    value += 1

      }
  }

    }
}

    ```
```


    As with struct or enum extensions, behavior extensions cannot introduce
As with struct or enum extensions, behavior extensions cannot introduce

    additional storage. Since behaviors are not types, behavior extensions cannot
additional storage. Since behaviors are not types, behavior extensions cannot

    declare protocol conformances. Behavior extensions can however constrain the
declare protocol conformances. Behavior extensions can however constrain the

    generic parameters of the behavior, including `Self`, to make the members
generic parameters of the behavior, including `Self`, to make the members

    available only on a subset of property and container types.
available only on a subset of property and container types.


    ## Impact on existing code
## Impact on existing code


    By itself, this is (almost, see below) an additive feature that doesn't impact
By itself, this is (almost, see below) an additive feature that doesn't impact

    existing code. However, it potentially obsoletes `lazy`, `willSet`/`didSet`,
existing code. However, it potentially obsoletes `lazy`, `willSet`/`didSet`,

    and `@NSCopying` as hardcoded language features.  We could grandfather these
and `@NSCopying` as hardcoded language features.  We could grandfather these

    in, but my preference would be to phase them out by migrating them to
in, but my preference would be to phase them out by migrating them to

    library-based property behavior implementations. (Removing them should be its
library-based property behavior implementations. (Removing them should be its

    own separate proposal, though.)
own separate proposal, though.)


    One potentially breaking change is the disambiguation rule for implicit
One potentially breaking change is the disambiguation rule for implicit

    getter accessors. The rule favors parsing as a named accessor, which would
getter accessors. The rule favors parsing as a named accessor, which would

    break code that intends to define a getter whose first statement uses trailing
break code that intends to define a getter whose first statement uses trailing

    closure syntax:
closure syntax:


    ```swift
```swift

    var foo: Int {
var foo: Int {

      doSomething { // parsed as named `doSomething` accessor
  doSomething { // parsed as named `doSomething` accessor

      }
  }

      return 0
  return 0

    }
}

    ```
```


    The potential impact is amplified if qualified accessor names with explicit
The potential impact is amplified if qualified accessor names with explicit

    arguments are considered:
arguments are considered:


    ```swift
```swift

    var foo: Int {
var foo: Int {

      x.doSomething(arg) { // still parsed as named `x.doSomething` accessor
  x.doSomething(arg) { // still parsed as named `x.doSomething` accessor

      }
  }

      return 0
  return 0

    }
}

    ```
```


    which strikes me as problematic. Ideas for a better disambiguation rule are
which strikes me as problematic. Ideas for a better disambiguation rule are

    welcome. An alternative to consider would be requiring non-core accessor
welcome. An alternative to consider would be requiring non-core accessor

    implementations to be decorated with an `accessor` keyword, like the
implementations to be decorated with an `accessor` keyword, like the

    requirement declarations are in the behavior:
requirement declarations are in the behavior:


    It's also worth exploring whether property behaviors could replace the
It's also worth exploring whether property behaviors could replace the

    "addressor" mechanism used by the standard library to implement `Array`
"addressor" mechanism used by the standard library to implement `Array`

    efficiently. It'd be great if the language only needed to expose the core
efficiently. It'd be great if the language only needed to expose the core

    conservative access pattern (`get`/`set`/`materializeForSet`) and let all
conservative access pattern (`get`/`set`/`materializeForSet`) and let all

    variations be implemented as library features. Note that superseding
variations be implemented as library features. Note that superseding

    `didSet`/`willSet` and addressors completely would require being able to apply
`didSet`/`willSet` and addressors completely would require being able to apply

    behaviors to subscripts in addition to properties, which seems like a
behaviors to subscripts in addition to properties, which seems like a

    reasonable generalization.
reasonable generalization.


    ## Alternatives considered
## Alternatives considered


    ### Using a protocol (formal or not) instead of a new declaration
### Using a protocol (formal or not) instead of a new declaration


    A previous iteration of this proposal used an informal instantiation
A previous iteration of this proposal used an informal instantiation

    protocol for property behaviors, desugaring a behavior into function calls, so
protocol for property behaviors, desugaring a behavior into function calls, so

    that:
that:


    ```swift
```swift

    var [lazy] foo = 1738
var [lazy] foo = 1738

    ```
```


    would act as sugar for something like this:
would act as sugar for something like this:


    ```swift
```swift

    var `foo.lazy` = lazy(var: Int.self, initializer: { 1738 })
var `foo.lazy` = lazy(var: Int.self, initializer: { 1738 })

    var foo: Int {
var foo: Int {

      get {
  get {

        return `foo.lazy`[varIn: self,
    return `foo.lazy`[varIn: self,

                          initializer: { 1738 }]
                      initializer: { 1738 }]

      }
  }

      set {
  set {

        `foo.lazy`[varIn: self,
    `foo.lazy`[varIn: self,

                   initializer: { 1738 }] = newValue
               initializer: { 1738 }] = newValue

      }
  }

    }
}

    ```
```


    There are a few disadvantages to this approach:
There are a few disadvantages to this approach:


    - Behaviors would pollute the namespace, potentially with multiple global
- Behaviors would pollute the namespace, potentially with multiple global

      functions and/or types.
  functions and/or types.

    - In practice, it would require every behavior to be implemented using a new
- In practice, it would require every behavior to be implemented using a new

      (usually generic) type, which introduces runtime overhead for the type's
  (usually generic) type, which introduces runtime overhead for the type's

      metadata structures.
  metadata structures.

    - The property behavior logic ends up less clear, being encoded in
- The property behavior logic ends up less clear, being encoded in

      unspecialized language constructs.
  unspecialized language constructs.

    - Determining the capabilities of a behavior relied on function overload
- Determining the capabilities of a behavior relied on function overload

      resolution, which can be fiddly, and would require a lot of special case
  resolution, which can be fiddly, and would require a lot of special case

      diagnostic work to get good, property-oriented error messages out of.
  diagnostic work to get good, property-oriented error messages out of.

    - Without severely complicating the informal protocol, it would be difficult to
- Without severely complicating the informal protocol, it would be difficult to

      support eager vs. deferred initializers, or allowing mutating access to
  support eager vs. deferred initializers, or allowing mutating access to

      `self` concurrently with the property's own storage without violating `inout`
  `self` concurrently with the property's own storage without violating `inout`

      aliasing rules. The code generation for standalone behavior decls can hide
  aliasing rules. The code generation for standalone behavior decls can hide

      this complexity.
  this complexity.


    Making property behaviors a distinct declaration undeniably increases the
Making property behaviors a distinct declaration undeniably increases the

    language size, but the demand for something like behaviors is clearly there.
language size, but the demand for something like behaviors is clearly there.

    In return for a new declaration, we get better namespacing, more
In return for a new declaration, we get better namespacing, more

    efficient code generation, clearer, more descriptive code for their
efficient code generation, clearer, more descriptive code for their

    implementation, and more expressive power with better diagnostics. I argue that
implementation, and more expressive power with better diagnostics. I argue that

    the complexity can pay for itself, today by eliminating several special-case
the complexity can pay for itself, today by eliminating several special-case

    language features, and potentially in the future by generalizing to other kinds
language features, and potentially in the future by generalizing to other kinds

    of behaviors (or being subsumed by an all-encompassing macro system). For
of behaviors (or being subsumed by an all-encompassing macro system). For

    instance, a future `func behavior` could conceivably provide Python
instance, a future `func behavior` could conceivably provide Python

    decorator-like behavior for transforming function bodies.
decorator-like behavior for transforming function bodies.


    ### Declaration syntax
### Declaration syntax


    Alternatives to the proposed `var [behavior] propertyName` syntax include:
Alternatives to the proposed `var [behavior] propertyName` syntax include:


    - A different set of brackets, `var (behavior) propertyName` or
- A different set of brackets, `var (behavior) propertyName` or

      `var {behavior} propertyName`. Parens have the problem of being ambiguous
  `var {behavior} propertyName`. Parens have the problem of being ambiguous

      with a tuple `var` declaration, requiring lookahead to resolve. Square
  with a tuple `var` declaration, requiring lookahead to resolve. Square

      brackets also work better with other declarations behaviors could be extended
  brackets also work better with other declarations behaviors could be extended

      to apply to in the future, such as subscripts or functions
  to apply to in the future, such as subscripts or functions

    - An attribute, such as `@behavior(lazy)` or `behavior(lazy) var`.
- An attribute, such as `@behavior(lazy)` or `behavior(lazy) var`.

      This is the most conservative answer, but is clunky.
  This is the most conservative answer, but is clunky.

    - Use the behavior function name directly as an attribute, so that e.g. `@lazy`
- Use the behavior function name directly as an attribute, so that e.g. `@lazy`

      works.
  works.

    - Use a new keyword, as in `var x: T by behavior`.
- Use a new keyword, as in `var x: T by behavior`.

    - Something on the right side of the colon, such as `var x: lazy(T)`.  To me
- Something on the right side of the colon, such as `var x: lazy(T)`.  To me

      this reads like `lazy(T)` is a type of some kind, which it really isn't.
  this reads like `lazy(T)` is a type of some kind, which it really isn't.

    - Something following the property name, such as `var x«lazy»: T` or `var
- Something following the property name, such as `var x«lazy»: T` or `var

      x¶lazy: T` (picking your favorite ASCII characters to replace `«»¶`). One
  x¶lazy: T` (picking your favorite ASCII characters to replace `«»¶`). One

      nice thing about this approach is that it suggests `self.x«lazy»` as a
  nice thing about this approach is that it suggests `self.x«lazy»` as a

      declaration-follows-use way of accessing the backing property.
  declaration-follows-use way of accessing the backing property.


    ### Syntax for accessing the backing property
### Syntax for accessing the backing property


    The proposal suggests `x.behaviorName` for accessing the underlying backing
The proposal suggests `x.behaviorName` for accessing the underlying backing

    property of `var (behaviorName) x`. The main disadvantage of this is that it
property of `var (behaviorName) x`. The main disadvantage of this is that it

    complicates name lookup, which must be aware of the behavior in order to
complicates name lookup, which must be aware of the behavior in order to

    resolve the name, and is potentially ambiguous, since the behavior name could
resolve the name, and is potentially ambiguous, since the behavior name could

    of course also be the name of a member of the property's type. Some
of course also be the name of a member of the property's type. Some

    alternatives to consider:
alternatives to consider:


    - Reserving a keyword and syntactic form to refer to the backing property, such as
- Reserving a keyword and syntactic form to refer to the backing property, such as

      `foo.x.behavior` or `foo.behavior(x)`. The problems with this are that reserving
  `foo.x.behavior` or `foo.behavior(x)`. The problems with this are that reserving

      a keyword is undesirable, and that `behavior` is a vague term that requires
  a keyword is undesirable, and that `behavior` is a vague term that requires

      more context for a reader to understand what's going on. If we support multiple
  more context for a reader to understand what's going on. If we support multiple

      behaviors on a property, it also doesn't provide a mechanism to distinguish between
  behaviors on a property, it also doesn't provide a mechanism to distinguish between

      behaviors.
  behaviors.

    - Something following the property name, such a `foo.x«lazy»` or `foo.x¶lazy`
- Something following the property name, such a `foo.x«lazy»` or `foo.x¶lazy`

      (choosing your favorite ASCII substitution for `«»¶`).
  (choosing your favorite ASCII substitution for `«»¶`).

    - Doing member lookup in both the property's type and its behaviors (favoring
- Doing member lookup in both the property's type and its behaviors (favoring

      the declared property when there are conflicts). If `foo` is known to be
  the declared property when there are conflicts). If `foo` is known to be

      `lazy`, it's attractive for `foo.clear()` to Just Work without additional
  `lazy`, it's attractive for `foo.clear()` to Just Work without additional

      syntax.  This has the usual ambiguity problems of overloading, of course; if
  syntax.  This has the usual ambiguity problems of overloading, of course; if

      the behavior's members are shadowed by the fronting type, something would be
  the behavior's members are shadowed by the fronting type, something would be

      necessary to disambiguate.
  necessary to disambiguate.


    ### Core accessors for property behavior implementation
### Core accessors for property behavior implementation


    The proposal as written specifies `get` and `set` as the only accessors that
The proposal as written specifies `get` and `set` as the only accessors that

    can be used to implement a property behavior. For efficiency, we may want
can be used to implement a property behavior. For efficiency, we may want

    to also allow the standard library to use addressors to implement standard
to also allow the standard library to use addressors to implement standard

    behaviors, though it would be nice to design a fundamental core accessor model
behaviors, though it would be nice to design a fundamental core accessor model

    that subsumes addressors too. It'd also be a reasonable extension to
that subsumes addressors too. It'd also be a reasonable extension to

    allow a property behavior declaration to itself instantiate behaviors, and
allow a property behavior declaration to itself instantiate behaviors, and

    define itself in terms of those behaviors' accessors.
define itself in terms of those behaviors' accessors.


    ### Behaviors for immutable `let` properties
### Behaviors for immutable `let` properties


    A previous revision of this proposal allowed for behaviors to apply to
A previous revision of this proposal allowed for behaviors to apply to

    `let` properties. Since we don't have an effects system (yet?), `let`
`let` properties. Since we don't have an effects system (yet?), `let`

    behavior implementations have the potential to invalidate the immutability
behavior implementations have the potential to invalidate the immutability

    assumptions expected of `let` properties, and it would be the programmer's
assumptions expected of `let` properties, and it would be the programmer's

    responsibility to maintain them. We don't support computed `let`s for the
responsibility to maintain them. We don't support computed `let`s for the

    same reason, so I suggest leaving `let`s out of property behaviors for now.
same reason, so I suggest leaving `let`s out of property behaviors for now.

    `let behavior`s could be added in the future when we have a comprehensive
`let behavior`s could be added in the future when we have a comprehensive

    design for immutable computed properties and/or functions.
design for immutable computed properties and/or functions.


    ## TODO
## TODO


    **Resilience rules for behaviors**: IMO, storage for behaviors should be
**Resilience rules for behaviors**: IMO, storage for behaviors should be

    fragile, since otherwise they require the equivalent of type metadata to
fragile, since otherwise they require the equivalent of type metadata to

    abstract their layout across resilience boundaries. Other optimizations
abstract their layout across resilience boundaries. Other optimizations

    are possible depending on how much flexibility we want to allow in
are possible depending on how much flexibility we want to allow in

    property behavior evolution. Some questions to answer include:
property behavior evolution. Some questions to answer include:


    - Can a behavior add new accessor requirements (with defaults)?
- Can a behavior add new accessor requirements (with defaults)?

    - Can a behavior introduce references to `self` if it doesn't already use
- Can a behavior introduce references to `self` if it doesn't already use

      it?
  it?

    - Can a behavior freely change its private, non-stored-property members?
- Can a behavior freely change its private, non-stored-property members?

    - Can a behavior relax its generic constraints, on either the property type or
- Can a behavior relax its generic constraints, on either the property type or

      on `Self`?
  on `Self`?


    Some fundamental constraints:
Some fundamental constraints:


    - A behavior can't resiliently add, take away, or change the eagerness of an
- A behavior can't resiliently add, take away, or change the eagerness of an

      initializer requirement.
  initializer requirement.

    - A behavior can't change whether it has a base property.
- A behavior can't change whether it has a base property.

    - A behavior can't remove accessor requirements.
- A behavior can't remove accessor requirements.