Argument labels on blocks arguments should be brought back.<br><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 22, 2017 at 4:26 AM Franklin Schrans via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">I don’t see why it should be available in function arguments.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The separation of the type and its label makes sense semantically, but the syntax doesn’t look as pretty anymore. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Writing something like </div><div class="gmail_msg"> <font face="Monaco" class="gmail_msg">foo(completion(success:error:): (Bool, Error) -> Void) {}</font></div><div class="gmail_msg">seems a bit convoluted to me. We first have to write the labels, then remember their order to write the type.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Minor: this also adds additional complexity when Xcode tries to generate a stub for the closure, as it needs to find the labels in the function name.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I was thinking of an implementation where closure types could have labels, but these could only be used within the body of that closure and would be <i class="gmail_msg">erased</i> elsewhere. This however still makes it difficult for the caller to figure out what each argument in the closure is representing when using <span style="font-family:Monaco" class="gmail_msg">foo</span>.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Franklin</div></div><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 22, 2017, at 9:05 AM, Iain Smith via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_7921274403641461926Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="auto" class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">Would this proposed syntax, using argument labels, also be available in function arguments?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">e.g </div><div class="gmail_msg">func items(withCompletion completion<span style="background-color:rgba(255,255,255,0)" class="gmail_msg">(success:error:): ([Item]?, NSError?) -> Void) {</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"> ...</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"> completion(success: items, error:nil)</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"> }</span></div><div class="gmail_msg"><br class="gmail_msg">On 22 Feb 2017, at 08:49, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">This was pointed out during the discussions surrounding this proposal and it was agreed that the type simplification was important.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There were several suggestions how to bring this back using different features - e.g. compound names that would contain the labels. For example:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">let callback(success:error:): (Bool, Error?) -> Void = ...</div><div class="gmail_msg">callback(success: true, error: nil)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This way the type itself wouldn't contain the label information, but the name of the variable would.</div><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_7921274403641461926Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="auto" class="gmail_msg"><div class="gmail_msg">I am quite interested in this as well, thanks for bringing it up! It was quite disappointing to fall back to multi argument method calls without labels as it was going against the emphasis on the value of labels in the language as well as decreasing readability of what is supposed to be self documenting code.<br class="gmail_msg"><br class="gmail_msg">Sent from my iPhone</div><div class="gmail_msg"><br class="gmail_msg">On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="auto" style="word-wrap:break-word" class="gmail_msg">Hi,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">When <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" class="gmail_msg" target="_blank">SE-0111</a> was approved, I noticed the implication it had when using closures as callbacks:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Writing</div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"> func foo(completion: (success: Bool) -> Void) {</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"> completion(success: true)</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"> }</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><br class="gmail_msg"></font></div><div class="gmail_msg">is no longer possible, because function types can’t have argument labels anymore, and the function has to be written:</div><div class="gmail_msg"><div class="gmail_msg"><font face="Monaco" class="gmail_msg"> func foo(completion: (Bool) -> Void) {</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"> completion(true)</font></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"> }</font></div></div><div class="gmail_msg"><font face="Monaco" class="gmail_msg"><br class="gmail_msg"></font></div><div class="gmail_msg">which doesn’t look very nice, especially as the number of the arguments increases.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">After talking to Chris Lattner about this, he referred me to <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html" class="gmail_msg" target="_blank">this</a> email.</div><div class="gmail_msg">I was wondering if there's been any further work or plans in restoring the use of argument labels in closures.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Franklin</div></div>
</div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>