<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 21, 2015, at 10:28 AM, Tal Atlas <<a href="mailto:me@tal.by" class="">me@tal.by</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">@Joe could you elaborate on the access pattern for these properties? Are you getting back a boxed object every time or is there some sort of magic going on so the caller thinks its getting the value inside the box but still has some way to access methods on the box (say reset for the lazy property)</div></div></blockquote><div><br class=""></div><div>There's no boxing, the behavior effectively just inserts itself in the property chain. It would still act as if you had defined a backing property yourself:</div><div><br class=""></div><div>var _backingProperty: Behavior<T></div><div>var property: T {</div><div> get {</div><div> return _backingProperty.getBehavior()</div><div> }</div><div> set {</div><div> _backingProperty.setBehavior(newValue)</div><div> }</div><div>}</div><div><br class=""></div><div>It's true that, if the behavior is implemented in terms of get/set accessors, that this may introduce temporary copies while drilling down into the property. We have other accessor patterns we allow that can avoid this inefficiency that we would use in production implementations of things like `lazy` and `delayed`.</div><div><br class=""></div><div>-Joe</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Dec 21, 2015 at 1:04 PM Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I really like the direction this is heading Joe! I agree it feels a lot nicer. It seems like the right long-term solution to me.<div class=""><br class=""></div><div class="">Making behaviors an explicit construct in the language may lead to possibilities in the future that we cannot today which would not exist with the ad-hoc approach. </div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2015, at 11:23 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">I played around a bit with the idea of a special behavior declaration. I think it feels a lot nicer, though it also feels like a much bigger language change if we go this route. Inside the declaration, you need to specify:<div class="">- what accessors the behavior supports, to be implemented by properties using the behavior,</div><div class="">- if the behavior controls storage, what that storage is, and what initialization logic it requires,</div><div class="">- if the behavior requires an initializer, and whether that initializer is used eagerly at property initialization or deferred to later, and</div><div class="">- what operations the behavior offers, if any.</div><div class=""><br class=""></div><div class="">Here's a quick sketch of how a behavior declaration could look. As a strawman, I'll use 'var behavior' as the introducer for a property behavior (leaving the door open to 'func behavior', 'struct behavior', etc. in the possible future). If you were going to reinvent computed properties from whole cloth, that might look like this:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class=""><div class="">var behavior computed<T> {</div></div><div class=""> // A computed property requires a `get` and `set` accessor.</div><div class=""><div class=""> accessor get() -> T</div></div><div class=""><div class=""> accessor set(newValue: T)</div></div><div class=""><div class=""><br class=""></div></div><div class=""> // Accessors for the property</div><div class=""><div class=""> get { return get() }</div></div><div class=""><div class=""> set { set(newValue) }</div></div><div class=""><div class="">}</div></div></blockquote><div class=""><div class=""><br class=""></div></div><div class="">lazy might look something like this:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class=""><div class="">var behavior lazy<T> {</div></div><div class=""> // lazy requires an initializer expression, but it isn't</div><div class=""> // used until after object initialization.</div><div class=""><div class=""> deferred initializer: T</div></div><div class=""><div class=""><br class=""></div></div><div class=""> // The optional storage for the property.</div><div class=""><div class=""> var value: T?</div></div><div class=""><div class=""><br class=""></div></div><div class=""> // Initialize the storage to nil.</div><div class=""><div class=""> init() {</div></div><div class=""><div class=""> value = nil</div></div><div class=""><div class=""> }</div></div><div class=""><div class=""><br class=""></div></div><div class=""> // Accessors for the property.</div><div class=""><div class=""> mutating get {</div></div><div class=""><div class=""> if let value = value {</div></div><div class=""><div class=""> return value</div></div><div class=""><div class=""> }</div></div><div class=""> // `initializer` is implicitly bound to the initializer expr as a</div><div class=""> // `@noescape () -> T` within the behavior's members.</div><div class=""><div class=""> let initialValue = initializer()</div></div><div class=""><div class=""> value = initialValue</div></div><div class=""><div class=""> return initialValue</div></div><div class=""><div class=""> }</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class=""> set {</div></div><div class=""><div class=""> value = newValue</div></div><div class=""><div class=""> }</div></div><div class=""><div class=""><br class=""></div></div><div class=""> // clear() operation for the behavior.</div><div class=""><div class=""> mutating func clear() {</div></div><div class=""><div class=""> value = nil</div></div><div class=""><div class=""> }</div></div><div class=""><div class="">}</div></div></blockquote><div class=""><div class=""><br class=""></div></div><div class="">Some behaviors like `lazy` and `resettable` want to take control of the storage to manage their semantics, but many behaviors are adapters independent of how the underlying behavior behaves. These kinds of behavior are easy to compose with other behaviors and to override base class properties with. You could use inheritance-like syntax to indicate a "wrapping" behavior like this, and commandeer `super` to refer to the underlying property. For instance, `synchronized`:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class=""><div class="">var behavior synchronized<T>: T {</div></div><div class=""><div class=""> get {</div></div><div class=""><div class=""> return sync { return super }</div></div><div class=""><div class=""> }</div></div><div class=""><div class=""> set {</div></div><div class=""><div class=""> return sync { return super }</div></div><div class=""><div class=""> }</div></div><div class=""><div class="">}</div></div></blockquote><div class=""><div class=""><br class=""></div></div><div class="">or `observing` didSet/willSet:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class=""><div class="">var behavior observing<T>: T {</div></div><div class=""><div class=""> accessor willSet(oldValue: T, newValue: T) { }</div></div><div class=""><div class=""> accessor didSet(oldValue: T, newValue: T) { }</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class=""> get { return super }</div></div><div class=""><div class=""> set {</div></div><div class=""> let oldValue = super</div><div class=""><div class=""> willSet(oldValue, newValue)</div></div><div class=""><div class=""> super = newValue</div></div><div class=""><div class=""> didSet(oldValue, newValue)</div></div><div class=""><div class=""> }</div></div><div class=""><div class="">}</div></div></blockquote><div class=""><br class=""></div><div class="">If you want to refer back to the containing `self`, we could support that too, and by treating behavior functions specially we should be able to maintain coherent semantics for backreferencing value types as well. Implementing `synchronized` with a per-object lock could look like this:</div><div class=""><br class=""></div><div class=""><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">var behavior synchronizedByObject<T>: T where Self: Synchronizable {</div><div class=""> get {</div><div class=""> return self.withLock { return super }</div><div class=""> }</div><div class=""> set {</div><div class=""> return self.withLock { return super }</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div></blockquote>(though the juxtaposed meanings of `super` and `self` here are weird together…we'd probably want a better implicit binding name for the underlying property.)<div class=""></div></div><div class=""><br class=""></div><div class="">-Joe</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAdB7f5kPel3wVVhZxLSddb-2FldjgOHakJarBMOyzAELLOuvB0h52c6hlV5Opv9Nqc9Z8EMVa3VYcHGKNDjHlrfGCTKQRmaVWUwLtvY9dMKtOJZnO9bG3Sym9sIOpYWxqPxlOADxujvnHBFqCiH3f0aqk39OZHV29ScuGERA4H56U3uY0oA55ORIisRewzOkvv-2Fk-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RVJ3oK8DhV2nk8GArr3gdPiHJ-2FGbeDKSQCjTA2mYAuInDp9uvnJQX0V8dj0Jx8lbT-2FsEUpX0hS9tvCJvls2ZIFuO-2BJW5NHDwi4EQ-2FlQVBQp8VYJKA9YwLYJPcOoctVotcvsm7cJuTMMGA0KbqboIOSth3dSurEJOrbPufo8C54x-2F4b74e71L8XDqgjEllxwg0YV5rAi7lPYFLpFahMMmBg-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>