<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 class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 6:52 AM, Al Skipp &lt;<a href="mailto:al_skipp@fastmail.fm" class="">al_skipp@fastmail.fm</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On 18 Dec 2015, at 03:27, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">Swift currently offers dot shorthand for static members of type Self in type contexts expecting a value of the type in question. &nbsp;This is&nbsp;most commonly used with enum cases.<br class=""><br class="">Swift does not currently offer shorthand for instance members. &nbsp;Introducing a shorthand for instance members would improve clarity&nbsp;and readability of code in common cases:<br class=""><br class="">anArray.map{$0.anInstanceMethod()}<br class=""><br class="">becomes:<br class=""><br class="">anArray.map(.anInstanceMethod())<br class=""><br class="">This shorthand would work in typing contexts expecting a single argument function. &nbsp;It would allow abbreviated access to any visible&nbsp;instance property getter or instance method on the type of the argument. &nbsp;Of course the return type would need to match the return&nbsp;type expected by the context or a type mismatch compiler error would occur.<br class=""><br class="">The readability advantage is arguably small but it does exist. &nbsp;The feature also aligns very well with an existing language feature.<br class=""><br class="">I think it’s an interesting idea and am wondering whether others feel like it is something worth pursuing or not.<br class=""><br class="">Matthew<br class=""></blockquote><br class=""><div class="">I’d be interested to hear peoples thoughts regarding this proposal. I’m personally in favour, but perhaps there are potential issues with the suggestion?</div><div class=""><br class=""></div><div class="">It’s only a small visual change, but I think it is a syntactic improvement. Let’s pretend for a moment that the current syntax was:</div><div class=""><b class="">anArray.map(.anInstanceMethod())</b></div><div class=""><br class=""></div><div class="">I’m not sure many people would argue for it to be changed to:</div><div class=""><b class="">anArray.map { $0.anInstanceMethod() }</b></div></div></div></blockquote><br class=""></div><div>Thanks Al. &nbsp;I should have also pointed out that the syntactic advantage is a bit greater in other contexts where the braces would not replace parentheses:</div><div><br class=""></div><div>struct S {</div><div>&nbsp; var predicate: String -&gt; Bool</div><div>}</div><div><br class=""></div><div>var s = S()</div><div>s.predicate = { $0.hasPrefix(“abc”) }</div><div><br class=""></div><div>vs</div><div>s.predicate = .hasPrefix(“abc”)</div><div><br class=""></div><div>It’s not a super important change, but maybe a low-hanging fruit item that can improve clarity and readability.</div><div><br class=""></div><div>Matthew</div></body></html>