<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="">Le 13 févr. 2016 à 21:23, Jérôme Duquennoy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi everyone,</div><div class=""><br class=""></div><div class="">First, I'm sorry, I have very few spare time currently, so I will only make a quick contribution to that topic.</div><div class=""><br class=""></div><div class="">I love this discussion, it is really an interesting feature, that could be very useful in some parts of my existing code.</div><div class="">I would like to raise a concern about the syntax : as Chris said, the square brackets are already heavily used for collections and subscript.</div><div class="">Given that swift might be used as a scripting language too, it will probably be written using a "simple" text editor like sublimeText, textMate, vi or equivalent ones in many cases. Those editor does not use sourceKit or LLVM to apply syntax coloring. The analysis is much simpler, often based on regexp.</div><div class="">I think that re-using the square brackets here would make it hard for them to provide accurate coloring, thus lowering the ease of use and reducing the attractiveness of swift as a scripting language.</div></div></div></blockquote><div><br class=""></div><div>I don’t think it is more complex to distinguish between subscript and behavior access (behavior as a leading dot), than between attribute or « macro » and behavior access (if we choose to use @ or # for behavior).</div><div><br class=""></div><div>That said, I’m not found either of the bracket proposal, but don’t have anything to propose to replace it though.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This feature is a +1 for me, but I would prefer an alternative syntax for it, like the @ prefix proposed in the review, or the # prefix proposed by Chris.</div><div class=""><br class=""></div><div class="">Jerome</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">Le 11 févr. 2016 à 07:13, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: TimesNewRomanPSMT; font-size: 14px; 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; float: none; display: inline !important;" class="">I think that something like this is a bit better aesthetically, since the [] delimiters are heavily array/collection/subscript-centric (which is a good thing). OTOH, this would be giving users access to the “#” namespace, which means that future conflicts would have to be resolved with backticks - e.g. if they wanted a “line” behavior, they’d have to use "var #`line` foo = 1738”. I guess the fact that we already have a solution to the imagined problem means that this isn’t a big concern in practice.</span></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>