[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Jan 22, 2016, at 7:38 PM, Ricardo Parada <rparada at mac.com> wrote:
> 
> Hi Joe,
> 
> I have a few of questions after reading your proposal.
> 
> Question #1 : 
> 
> Let’s say that the property behavior has an init() method as in your example for the lazy property behavior where you simply assign nil to the value.  After the declaration of the lazy behavior you show how to use this behavior for a variable declared in the global scope, It appears to me that the init() gets called at the time the property is declared because you mention in the comment that the property is inited to nil:
> 
> var [lazy] x = 1738 // Allocates an Int? behind the scenes, inited to nil
> 
> My question is as follows: What about when the property is declared inside a class?  At what point is the init() called?

The init() is called at the beginning of initialization, as if the behavior's storage were expanded out with an initial value:

class Foo {
  var [lazy] x = 1738

  // Compiler expands this behind the scenes:
  var `x.[lazy]`: Int? = lazy.init()
}

It's useful for this to happen later, since many behaviors would want to allow out-of-line initialization in the containing type's init method:

class Bar {
  var [runcible] x: Int

  init() {
    x = 679 // Would like runcible.init(679) to trigger here
  }
}

There are some subtleties to this, so I wanted to subset that out as a separate extension.

> 
> 
> Question #2 :
> 
> In your example for the synchronized property behavior, you have the following line of code in the declaration of the behavior:
> 
>   var value: Value = initialValue
> 
> The get and the set accessors use withLock { … } to get / set the value.  However, the code above that stores the initialValue in the value variable does not use withLock { … }.  Does it matter?  And similar to question #1, at what time is this code executed?

The initializer will occur at the start of the container's initialization, as in the previous example (though `synchronized` is really somewhere you want to be able to trigger the initialization out-of-line). For `synchronized`, it's unlikely to be necessary to synchronize the initialization, since a class in Swift can't be shared across threads until it's already fully initialized.

> 
> 
> Comments About this Proposal:
> 
> I’ve been following the threads on property behaviors as it is one of my favorite threads.  I don’t always understand everything that you are all saying, for example, I am not sure if I understand what you guys means by out-of-line initialization in this context.  
> 
> In general, I like the proposal.   At first I thought that the square brackets notation could be confusing as it looks like an array.  I understand there aren’t many options to use.  However, now that I think of this as a list of property behaviors preceding the property name, I think the square brackets are the right choice.  

Thanks! Don't be afraid to ask questions about things that aren't clear. When I refer to out-of-line initialization, I refer to the ability to initialize properties after their initial declaration. For local properties, this is possible by assigning the initial value to the property after its immediate declaration:

func foo() {
  var x: Int
  // some other stuff happens that doesn't use x
  x = 22 // out-of-line initialization of x
}

and for properties inside classes, this is possible during the class's `init` implementations:

class Foo {
  var x: Int

  init(x: Int) {
    self.x = x // out-of-line initialization of self.x
  }
}

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/a2dfdb31/attachment.html>