<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div>Am 19.02.2016 um 19:53 schrieb Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 19, 2016, at 8:30 AM, Matt Whiteside <<a href="mailto:mwhiteside.dev@gmail.com" class="">mwhiteside.dev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Response inline below...</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Feb 19, 2016, at 06:14, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 19 Feb 2016, at 02:56, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">In discussion with the core team, we've also strongly come in favor of applying behaviors to properties using attribute syntax, e.g.:<div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">@lazy var x = 111</div><div class="">@delayed var x: Int</div><div class=""><br class=""></div></blockquote>They're definitely attribute-like, and we think it makes sense for behaviors to be the first of hopefully many kinds of user-defined behaviors. What do you all think of this direction?</div></div></blockquote><br class=""></div><div class="">Are they though? We’ve been discussing this a lot in the thread on enforcing super method requirements; while my preference in that case is for an attribute, I feel it is appropriate there because they’re more like directives and informative, and will generate warnings (and possibly errors too) in the same way as @warn_unused_result does. A lot of other attributes are either informational or are produce some kind of restriction that the compiler warns us about (or errors on).</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think Haravikk makes a good point here. Currently, the `@` symbol seems like a holding ground for miscellaneous compiler directives and backwards compatibility issues (e.g., @objc, @IBOutlet). So from this view, putting behaviors, which are a forward looking, swift native idea, under the ‘@‘ symbol, seems debatable.</div></div></div></blockquote><div><br class=""></div><div>I don't think that was ever our long term intent for `@`. We always intended to open the space up to user annotations at some point. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">The syntax Haravikk proposes below makes sense to me. Does it cause big problems from a compiler implementer’s standpoint?</div></div></div></blockquote><div><br class=""></div><div>It could be made to work today. 'var' <identifier> <pattern>' isn't currently a valid production. It would however interfere with the potential future ability to destructure structs or classes in 'var' bindings; we could conceivably allow `var CGPoint(x: x, y: y) = point` or something like it in the broad future.</div></div></div></blockquote><div><br></div>As that's something I'd like to have sometime, I wouldn't want to block that path.<div><br></div><div>-Thorsten </div><div><br></div><div><br><blockquote type="cite"><div><div><div><br class=""></div><div>-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">Matt</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">However, property behaviours are more like defining protocols for properties, which is clearly very different from an attribute, and IMO not really compiler magic either. I think a keyword makes most sense, such as behaviour(lazy), though personally I don’t see why we can’t just include the names directly, i.e:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>var lazy x = 111</font></div><div class=""><br class=""></div><div class="">Isn’t ambiguous, because the right most token (x) is used as the name, var is an explicitly defined keyword, therefore everything else (lazy) can be looked up as a behaviour, in much the same way as types would be. I know there’s some risk of naming collision, but I don’t think it’s all that high, and if property behaviours are functional enough there should be no reason to add any new keywords for use on properties in future as they will be added as behaviours in the standard library. So long as they’re a way to disambiguate your property behaviours from any in the standard library (which will be needed anyway) then I think it’s fine, even when you’re dealing with stuff like:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>static final internal var lazy synchronized x = 111</font></div><div class=""><br class=""></div><div class="">If we require the order to be:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>[static, final, private|internal|public] [var|let] [behaviours…] [name]</div><div class=""><br class=""></div><div class="">Then I don’t think there should be any real problems. This may even already be how it is, I’m not sure as this is how I structure them anyway.</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>