[swift-evolution] [Proposal] Property behaviors

Ricardo Parada rparada at mac.com
Fri Jan 22 21:38:12 CST 2016

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?

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?

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.  

Thank you

> On Jan 22, 2016, at 7:33 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> I've revised my proposal again based on more feedback. Syntax changes include:
> - adopting John McCall's declaration-follows-use syntax for behavior declarations. I think this looks nice and provides a reasonable framework for binding all the fiddly bits of a property, such as its type, name, and initializer.
> - changing the proposed syntax for behavior member lookup to 'property.[behavior].member', as suggested by Tal Atlas and others. I think this has a nice symmetry with the `var [behavior]` declaration syntax, and doesn't occupy any new sigils. On the other had, Curt Clifton and others have raised the point that it could be mistaken for a subscript at a glance.
> To reduce the complexity of the initial feature review, I've also removed many of the bells and whistles from this initial version for separate consideration. For now, I'm saying initializer requirements are always "eager" (can't refer to self) and always inline-initialized. This imposes some inconvenience on some use cases, but is an additive feature. I've also left behavior composition, extending behaviors, overloading behaviors, and name binding as future extensions. Joe Pamer raised some design and technical challenges around how type inference should work with behaviors too, which I think deserve focused discussion, so I'm sidestepping those issues by starting out saying properties with behaviors always need an explicit type. Here's the updated proposal:
> https://gist.github.com/jckarter/66ae8fb361c0d57b3227
> And for reference, previous iterations:
> https://gist.github.com/jckarter/50b838e7f036fe85eaa3
> https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160122/5bfdd90e/attachment.html>

More information about the swift-evolution mailing list