<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>That's an interesting idea. It's a further shorthand for closures rather than an extension of dot shorthand in a new type context. 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. 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 <<a href="mailto:sean@fifthace.com">sean@fifthace.com</a>> 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> someArray.map({ $0.property })</span><br><span> 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> someArray.map($0.property)</span><br><span> 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> someArray.map({ $.property })</span><br><span></span><br><span>And finally, combined with the single-statement shortcut:</span><br><span></span><br><span> 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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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. I’d rather use the currently possible { $0.member } syntax. The point of the idea is to remove syntactic noise. </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. 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 <<a href="mailto:jj@johanjensen.dk">jj@johanjensen.dk</a>> 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<A, B, C>(f: A -> B -> C) -> (B -> A -> C) {</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> return { valB in</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> return { valA in</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> return f(valA)(valB)</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></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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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 <<a href="mailto:al_skipp@fastmail.fm">al_skipp@fastmail.fm</a>> 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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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. 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. 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. It would allow abbreviated access to any visible instance property getter or instance method on the type of the argument. 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. 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. 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> var predicate: String -> 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>