Great work Joe! I really like this.<div><br></div><div>I presume the standard library will come with the existing lazy behavior.<div><br></div><div>It would be nice to have access the sync function used by Swift 2 &#39;lazy&#39;, but for new behaviors. It may be that the usefulness/consistency of this is contingent on lazy being implemented only with the standard library (maybe dispatch?)</div><div><br></div><div>My only concern is that it&#39;s not currently obvious (without the proposal) what the type requirements of a behavior are. It feels like it could have a protocol but probably doesn&#39;t need one as it&#39;s a language feature. <font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">A badly conforming behavior would really need good</span></font> and accurate error messages.</div><div><br></div><div>It would be important that these are debugable, and that lldb prints something sensible when you print an instance using them.</div><div><br></div><div>I missed it if it was mentioned, but access to a behavior (i.e. <font size="2"><span style="background-color:rgba(255,255,255,0)">foo<span class="pl-k" style="box-sizing: border-box;">.</span>resettable<span class="pl-k" style="box-sizing: border-box;">.</span>reset()) should probably be private by default, and perhaps allow other access modifiers<span></span>.</span></font></div><div><br>On Friday, 18 December 2015, Michel Fortin via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 17 déc. 2015 à 16:36, Joe Groff &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;jgroff@apple.com&#39;)">jgroff@apple.com</a>&gt; a écrit :<br>
<br>
&gt;&gt; On Dec 17, 2015, at 1:14 PM, Michel Fortin &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;michel.fortin@michelf.ca&#39;)">michel.fortin@michelf.ca</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; About synchronized access, it seems to me that it&#39;d be advantageous if implementing subscript in a behaviour was optional. This way you can force access of a property through a synchronized block which will help avoid races:<br>
&gt;&gt;<br>
&gt;&gt;      var (synchronized) data: (x: Int, y: Int, z: Int)<br>
&gt;&gt;<br>
&gt;&gt;      func test() {<br>
&gt;&gt;              data.synchronize { (data) in<br>
&gt;&gt;                      data.x += 1<br>
&gt;&gt;                      data.y += data.x<br>
&gt;&gt;                      data.z += data.y<br>
&gt;&gt;              }<br>
&gt;&gt;      }<br>
&gt;<br>
&gt; Interesting. IIUC, if a behavior didn&#39;t supply a subscript operation, then the property could *only* be accessed through its behavior interface?<br>
<br>
Exactly. It&#39;s much better than having a `fatalError(&quot;Don&#39;t access directly&quot;)` in the subscript getter.<br>
<br>
--<br>
Michel Fortin<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;michel.fortin@michelf.ca&#39;)">michel.fortin@michelf.ca</a><br>
<a href="https://michelf.ca" target="_blank">https://michelf.ca</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>