<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=""><blockquote type="cite" class=""><span class="" style="display: inline !important;">That is a fair position. It sounds like you oppose this shorthand for methods that require arguments but not for nullary methods and not for property getters. Is that correct? Do you believe it is valuable in those cases?</span></blockquote><br class=""></div><div class="">Correct. I’m for foo(.aMethod) and foo(.aProperty), but not foo(.aMethod(withArgs)), because the former maps pretty nicely to what we already have, and the latter can be seriously confusing.</div><div class=""><br class=""></div><div class="">PS. I’d like to try and analyze my Swift codebases to see how I usually use closures with things like map, just to have some (admittedly biased) data on what kind of patterns are common in practice.</div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 19 Dec 2015, at 16:21, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" 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=""><br class="Apple-interchange-newline">On Dec 19, 2015, at 2:19 AM, Radosław Pietruszewski <<a href="mailto:radexpl@gmail.com" class="">radexpl@gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">anArray.map(.hasPrefix(“foo”))<br class=""></blockquote><br class="">I’m against this. Yes, it extends the functionality of the proposal even more and could allow for more closures to be rewritten in this style — but at a severe cost in clarity IMHO.<br class=""><br class="">I mean, with `map(.aMethod)`, you’re passing a reference to a method available on the receiver. This is actually very similar to passing `foo(.EnumCase)`, as in both cases we’re accessing a static member of the type. (Yes, also with the former example if you consider instance methods as curried functions on the type that take self as the first parameter.) So, there’s some nice symmetry and predictability, even if the dot-syntax has more than one use.<br class=""><br class="">But with `map(.hasPrefix(“foo”))`, you’re implicitly constructing a new closure, that calls a method, and passes an argument. This isn’t immediately obvious. There’s no symmetry. It looks as if I was passing the result of calling some method, and the dot at the beginning meant something else (cf the se-0009 review thread). I couldn’t figure easily figure out that this is actually implicit contents of a new closure.<br class=""><br class="">The potential for confusion is great. I’m not convinced the benefit outweighs the cost here.<br class=""></blockquote><br 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=""><span 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; float: none; display: inline !important;" class="">That is a fair position. It sounds like you oppose this shorthand for methods that require arguments but not for nullary methods and not for property getters. Is that correct? Do you believe it is valuable in those cases?</span><br 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=""><br 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" 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=""><br class="">— Radek<br class=""><br class=""><blockquote type="cite" class="">On 19 Dec 2015, at 02:10, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 18, 2015, at 1:36 PM, Radosław Pietruszewski <<a href="mailto:radexpl@gmail.com" class="">radexpl@gmail.com</a>> wrote:<br class=""><br class="">Interesting! I’d definitely be for some shortcut syntax here, as this seems to be a very, very common pattern. Passing a function to, say, `map` is so much easier and cleaner than passing a method in Swift — even though Swift generally always prefers methods to functions!<br class=""><br class="">I haven’t spent too much thinking this through, but I think this is sound.<br class=""><br class="">For contexts where a T is expected, .foo means T.foo<br class=""><br class="">But it’s not ambiguous here, because we’re expecting T -> U here, and functions can’t have static members (or any members for that matter :P). So passing a .foo could unambiguously mean T.foo(T) — an instance method on T, returning U.<br class=""><br class="">I’d be for dropping the parens, they seem unnecessary, and are confusing (we’re passing a function, not calling it). It should be unambiguous with properties since methods and properties share a name space.<br class=""><br class="">And, speaking of, I’d also just make it work with properties with the same syntax. So array.map(.foo) would call $0.foo() if `foo` is a method, or $0.foo if `foo` is a property.<br class=""></blockquote><br class="">I probably should have showed more examples in my original post.<br class=""><br class="">Making this work with property getters was one of the examples I posted in the other thread:<br class=""><br class="">anArray.map(.aProperty)<br class=""><br class="">The reason I used parentheses in the example of a method that takes no argument is that what we’re actually doing is binding the non-self arguments. This is more clear with an example of a method that does take additional arguments:<br class=""><br class="">anArray.map(.hasPrefix(“foo”))<br class=""><br class="">I hadn’t tried declaring property and no argument method with the same name until you said this. You are correct that it’s unambiguous. I didn’t realize this when I first posted this idea. <br class=""><br class="">If we don’t omit them it’s always clear whether we are passing a property or a method. I think requiring the parentheses is probably worth the syntactic cost. It also allows for a straightforward rewrite to a closure by wrapping the expression in braces and placing $0 prior to the dot.<br class=""><br class=""><blockquote type="cite" class=""><br class="">(Am I missing something?)<br class=""><br class="">— Radek<br class=""><br class=""><blockquote type="cite" class="">On 18 Dec 2015, at 04:27, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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. This is most commonly used with enum cases.<br class=""><br class="">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:<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. 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.<br class=""><br class="">The readability advantage is arguably small but it does exist. 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="">_______________________________________________<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</blockquote></blockquote></blockquote></blockquote></div></blockquote></div><br class=""></body></html>