<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>That's an interesting idea. &nbsp;It's a further shorthand for closures rather than an extension of dot shorthand in a new type context. &nbsp;I wonder if this would apply in contexts where the dot shorthand wouldn't.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">From a readability point of view I definitely prefer the dot shorthand. &nbsp;The $ after the opening parenthesis doesn't leave enough "whitespace" for my eyes and makes things appear cluttered.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">someArray.map($.property)</span></font></div></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">someArray.map(.property)</span></div><div id="AppleMailSignature"><br>That said, I do like the idea of being able to drop the 0 in more complex single-argument closures.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Matthew<br><br><br>Sent from my iPad</div><div><br>On Dec 18, 2015, at 10:15 AM, Sean Heber &lt;<a href="mailto:sean@fifthace.com">sean@fifthace.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><span>For me there are two sources to the feeling of noise with simple single-statement closures and using $0, etc. - The first are the braces that seem redundant when there’s only a single statement, and the second is the presence of $0. </span><br><span></span><br><span>I played around a bit, and this is probably just a personal preference thing, but I don’t think it’s the $ that bothers me, really, but instead it is the digit that makes it feel noisy. When I change $0 to $a, $b, etc. suddenly the code doesn’t feel so noisy to me. This may simply be because I rarely ever put a number in my variable names, and if I do, I almost always start at 1 and not 0. :P Again, this might just be me. :)</span><br><span></span><br><span> &nbsp;&nbsp;&nbsp;someArray.map({ $0.property })</span><br><span> &nbsp;&nbsp;&nbsp;someArray.map({ $a.property })</span><br><span></span><br><span>Then it occurred to me that for the simple case of doing a map or filter or whatever using a single method call, what if Swift could instead make an assumption that if there’s a $ variable outside of a closure, we meant to start a single-statement closure so something like this could be possible:</span><br><span></span><br><span> &nbsp;&nbsp;&nbsp;someArray.map($0.property)</span><br><span> &nbsp;&nbsp;&nbsp;someArray.map($a.property)</span><br><span></span><br><span>And going farther with this, in the case where there’s only a single argument in the closure, maybe we could skip the number/letter entirely and just use are bare $ instead of $0:</span><br><span></span><br><span> &nbsp;&nbsp;&nbsp;someArray.map({ $.property })</span><br><span></span><br><span>And finally, combined with the single-statement shortcut:</span><br><span></span><br><span> &nbsp;&nbsp;&nbsp;someArray.map($.property)</span><br><span></span><br><span>l8r</span><br><span>Sean</span><br><span></span><br><span></span><br><blockquote type="cite"><span>On Dec 18, 2015, at 9:31 AM, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Johan, you are right that all of this is possible but it seems rather verbose to me. &nbsp;I’d rather use the currently possible { $0.member } syntax. &nbsp;The point of the idea is to remove syntactic noise. &nbsp;</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It’s reasonable to argue that this isn’t necessary, but in that case the current state suffices IMO. &nbsp;We don’t need a more verbose alternative to what we already have.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Dec 18, 2015, at 9:00 AM, Johan Jensen &lt;<a href="mailto:jj@johanjensen.dk">jj@johanjensen.dk</a>&gt; wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I’m not very fond of having just a single dot in front of the method call, as it could easily be missed.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>In the case of s.predicate = .hasPrefix("abc"), I would prefer something slightly more expressive.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>As it is right now in Swift, accessing methods directly gives you a curried function back, which expects the object instance as argument in the first call, and the rest in the second call.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>E.g. String.hasPrefix("abcd")("a") is the same as "abcd".hasPrefix("a")</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Flipping the arguments like this:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>func flip&lt;A, B, C&gt;(f: A -&gt; B -&gt; C) -&gt; (B -&gt; A -&gt; C) {</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;return { valB in</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return { valA in</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return f(valA)(valB)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;}</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>}</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>String.hasPrefix("abcd")("a")</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>let myHasPrefix = flip(String.hasPrefix)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>myHasPrefix("a")("abcd")</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>…would allow us to write the following:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>s.predicate = flip(String.hasPrefix("abcd"))</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Perhaps it could be extended to something akin to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>s.predicate = String::hasPrefix("abcd")</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The currying only works for methods and not for properties, so this isn’t currently possible to express like the above:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>["John", "Rachel", "Thomas"].map({ $0.endIndex })</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>["John", "Rachel", "Thomas"].map({ $0.characters.count })</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>—Johan</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Fri, Dec 18, 2015 at 2:05 PM, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On Dec 18, 2015, at 6:52 AM, Al Skipp &lt;<a href="mailto:al_skipp@fastmail.fm">al_skipp@fastmail.fm</a>&gt; wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On 18 Dec 2015, at 03:27, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>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 most commonly used with enum cases.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Swift does not currently offer shorthand for instance members. &nbsp;Introducing a shorthand for instance members would improve clarity and readability of code in common cases:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>anArray.map{$0.anInstanceMethod()}</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>becomes:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>anArray.map(.anInstanceMethod())</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>This shorthand would work in typing contexts expecting a single argument function. &nbsp;It would allow abbreviated access to any visible instance property getter or instance method on the type of the argument. &nbsp;Of course the return type would need to match the return type expected by the context or a type mismatch compiler error would occur.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The readability advantage is arguably small but it does exist. &nbsp;The feature also aligns very well with an existing language feature.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I think it’s an interesting idea and am wondering whether others feel like it is something worth pursuing or not.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Matthew</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>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?</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>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:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>anArray.map(.anInstanceMethod())</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I’m not sure many people would argue for it to be changed to:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>anArray.map { $0.anInstanceMethod() }</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>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:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>struct S {</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> &nbsp;var predicate: String -&gt; Bool</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>}</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>var s = S()</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>s.predicate = { $0.hasPrefix(“abc”) }</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>vs</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>s.predicate = .hasPrefix(“abc”)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>It’s not a super important change, but maybe a low-hanging fruit item that can improve clarity and readability.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Matthew</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> _______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span></span><br></div></blockquote></body></html>