<div dir="ltr"><div class="gmail_extra"><span style="font-size:12.8px">Here are some of my thoughts from reading through the current version (</span><a href="https://gist.github.com/jckarter/50b838e7f036fe85eaa3" target="_blank" style="font-size:12.8px">https://gist.github.com/jckarter/50b838e7f036fe85eaa3</a><span style="font-size:12.8px">)</span><span style="font-size:12.8px">. Apologies if this duplicates what anyone else has said; the thread is kind of unmanageable :)</span><div style="font-size:12.8px"><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  // Behaviors can declare that properties using the behavior require<br>  // a `deferred initializer` expression. When deferred, the<br>  // initializer expression is assumed to be evaluated after<br>  // initialization of the containing value, which allows it to refer<br>  // to `self`. If declared, `initializer` is bound in accessors and<br>  // methods of the behavior.<br>  deferred initializer: Value</blockquote><div><br></div><div>This seems like an important feature, but the syntax is strange to me. It looks like it would be declaring storage inside the behavior, but it&#39;s really specifying the type of something used in the containing object&#39;s property declaration.</div></div><div><br></div><div>I can think of a couple alternatives:</div><div><br></div><div>1. Rather than passing an initial value in the containing object like &quot;var [lazy] prop = someInitialValue&quot;, pass it explicitly as a parameter to the behavior,</div><div>    like &quot;var [ lazy({ return someInitialValue }) ] prop: Type&quot;</div><div><br></div><div>    I think it might be generally useful for behaviors&#39; initializers to take arguments; it&#39;d handle more than just this case. For example, you could have a behavior called synchronized(maxConcurrentRequests: Int) which would allow arguments passed to affect the behavior&#39;s...behavior.</div><div><br></div><div>2. Make the &quot;deferred&quot;-ness a modifier/attribute on the behavior declaration, like &quot;public @deferred var behavior lazy&lt;Value&gt;: Value { ... }&quot;, which would make the implicit initialValue inaccessible from the behavior&#39;s init(). The same with @eager.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">x.lazy.clear() // Invokes `lazy`&#39;s `clear` method</blockquote><div><br></div><div>As I think others have mentioned, this is ambiguous if x itself has a property called &quot;lazy&quot;. I&#39;d be reasonably satisfied with any of the proposed solutions to this.</div><div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  base var value: Int</blockquote><div><br></div><div>I don&#39;t think I like the fact that this needs to be explicitly declared. Do all behaviors have to use the same identifier for them to be composable? Could you use &quot;super&quot; to mean this, instead of explicitly declaring a base property?</div></div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Accessor requirements can be made optional by specifying a default implementation:<br>  mutating accessor willSet(newValue: Value) {<br>    // do nothing by default<br>  }</blockquote><div><br></div><div>Up until this point, I was thinking of accessor declarations like protocol requirements, in that they have no implementation (&quot;accessor foo()&quot; like &quot;func foo()&quot;). I think the lack of implementation is what makes it clear that these are requirements, not things the behavior is implementing.</div><div><br></div><div>So perhaps you could use the &quot;optional&quot; specifier to indicate that they aren&#39;t required, rather than allowing an implementation block in the behavior. &quot;optional accessor foo()&quot; would allow the behavior&#39;s implementation to use &quot;foo?()&quot;.</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">var [foo] x: Int { </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">    bar(myArg) { print(myArg) } // `arg` explicitly bound to `myArg` </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">}</blockquote><div><br></div><div>Why not require a type annotation for parameters here? I recognize this matches the current syntax of set(newValue), but it would be more flexible if this were more like a function declaration.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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 the implementation of a single accessor named &quot;get&quot;.</blockquote><div><br></div><div>This seems a bit vestigial. Maybe it could be allowed only when a computed property is declared without using any behaviors.</div><div><br></div><div>A few more questions:</div><div><br></div><div>- Can a behavior&#39;s own properties/storage use other behaviors? Can a behavior be recursive?</div><div><br></div><div>- What of deinitializers for behaviors? Would it be possible, for example, to make an observable behavior whose willSet/didSet run during init and deinit (which Swift&#39;s current property observers can&#39;t do)?</div><div><br></div><div>- Are accessor implementations allowed to access the &quot;current&quot; property value? Currently, inside &quot;var foo { didSet { … } }&quot; you can access the current value by referencing &quot;foo&quot;.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Overall this looks great. I&#39;m looking forward to it. :-)</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Jacob Bandes-Storch<br></div></div><div><br></div></div></div></div></div>