<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=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 2:07 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="">Thanks everyone for the first round of feedback on my behaviors proposal. I've revised it with the following changes:<br class=""><br class="">- Instead of relying on mapping behaviors to function or type member lookup, I've introduced a new purpose-built 'var behavior' declaration, which declares the accessor and initializer requirements and provides the storage and behavior methods of the property. I think this gives a clearer design for authoring behaviors, and allows for a more efficient and flexible implementation model.<br class="">- I've backed off from trying to include 'let' behaviors. As many of you noted, it's better to tackle immutable computed properties more holistically than to try to backdoor them in.<br class="">- I suggest changing the declaration syntax to use a behavior to square brackets—'var [behavior] foo'—which avoids ambiguity with destructuring 'var' bindings, and also works with future candidates for behavior decoration, particularly `subscript`.<br class=""></div></div></blockquote><div><br class=""></div></div>Syntax comments:<div class=""><br class=""></div><div class="">I still think these feel attribute-like to me, but if we’re not just going to use @lazy — and I agree that that does have some problems —I’m fine with [lazy].<br class=""><div class=""><br class=""></div><div class="">"var behavior" is really weird to me, and the <T> doesn’t seem to fit and is pretty redundant in the common case. How about this:</div></div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> "behavior" var-or-let "[" identifier-list "]" (identifier | </font><span style="font-family: Menlo;" class="">"</span><font face="Menlo" class="">_</font><span style="font-family: Menlo;" class="">")</span><span style="font-family: Menlo;" class=""> ":" identifier (</span><span style="font-family: Menlo;" class="">"="</span><span style="font-family: Menlo;" class=""> </span><span style="font-family: Menlo;" class="">identifier)? </span><span style="font-family: Menlo;" class="">("where" generic-requirement-list)?</span></div><div class=""><br class=""></div><div class="">So, for example,</div><div class=""><font face="Menlo" class=""> behavior var [lazy] _ : T where T : IntegerLiteralConvertible { … }</font></div><div class=""><br class=""></div><div class="">This is definitely taking the idea of “this is basically a macro” and running with it. Think of the stuff between “behavior” and the optional “where” as being a pattern for the declaration. So this pattern would match:</div><div class=""><font face="Menlo" class=""> var [lazy] x: Int</font></div><div class="">but not:</div><div class=""><font face="Menlo" class=""> let [lazy] x: Int</font></div><div class="">or:</div><div class=""><font face="Menlo" class=""> var [lazy] x : Int = foo()</font></div><div class=""><br class=""></div><div class="">The behavior list has to match exactly (or maybe as sets?).</div><div class=""><br class=""></div><div class="">The property name, if bound, expands to a string literal within the behavior.</div><div class=""><br class=""></div><div class="">The type name is always a generic parameter. This interferes with the ability to make a pattern that only matches a concrete type, but I think that’s okay.</div><div class=""><br class=""></div><div class="">The initializer name, if bound, expands to the original expression within the behavior. Maybe it should be coerced to type T first? Not sure.</div><div class=""><br class=""></div><div class="">John.</div></body></html>