<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div>Sent from my iPhone</div><div><br>On 19 Jul 2016, at 23:30, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><span>on Tue Jul 19 2016, James Froggatt <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br><span></span><br><blockquote type="cite"><span>Made a draft proposal to start this discussion, and help define the</span><br></blockquote><blockquote type="cite"><span>problem. I'm not too biased either way, this isn't a particularly</span><br></blockquote><blockquote type="cite"><span>major aspect of the language, but obviously the proposal has to</span><br></blockquote><blockquote type="cite"><span>justify the potential change to the language. This is something due</span><br></blockquote><blockquote type="cite"><span>for re-evaluation since Swift 3 removed the ‘first-argument</span><br></blockquote><blockquote type="cite"><span>hide-by-default’ rule, which now makes this simplification possible.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hoping to get an idea of what people's opinions are on this, and the</span><br></blockquote><blockquote type="cite"><span>subject of local parameter names leaking to the user in</span><br></blockquote><blockquote type="cite"><span>general. Please let me know if my reasoning is flawed, anywhere.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## Introduction</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Swift's current treatment of local parameter names is rather</span><br></blockquote><blockquote type="cite"><span>odd. They're hidden from the caller most of the timer, where an</span><br></blockquote><blockquote type="cite"><span>external parameter label is specified, but otherwise (if a ‘_’ is</span><br></blockquote><blockquote type="cite"><span>used), they actually leak out into Xcode's autocomplete. External</span><br></blockquote><blockquote type="cite"><span>labels are intended to add clarity, so the local names seem like they</span><br></blockquote><blockquote type="cite"><span>should be an implementation detail. Otherwise, why don't local names</span><br></blockquote><blockquote type="cite"><span>show up for labelled parameters, too?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The main point in the language affected by this ambiguity is in the</span><br></blockquote><blockquote type="cite"><span>protocol definition, where local names can be specified, but are only</span><br></blockquote><blockquote type="cite"><span>in any way useful for autocomplete when implementing the protocol,</span><br></blockquote><blockquote type="cite"><span>making them useless to the language itself. </span><br></blockquote><span></span><br><span>They're useful in documentation comments, which you might have realized</span><br><span>if you had included them in your examples ;-)</span><br><span></span><br><blockquote type="cite"><span>This proposal, if accepted, would simplify the language by removing</span><br></blockquote><blockquote type="cite"><span>the ability to declare local parameter names from protocols, reducing</span><br></blockquote><blockquote type="cite"><span>their function signatures to just the actual requirements - label and</span><br></blockquote><blockquote type="cite"><span>type.</span><br></blockquote><span></span><br><span>Code completion and doc comments are good enough reasons (for me) to</span><br><span>keep this capability. I am opposed to any change here.</span><br><div style="direction: inherit;"><br></div></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Thank you :).</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><blockquote type="cite"><span>## Motivation</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Consider the following code:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>````swift</span><br></blockquote><blockquote type="cite"><span>protocol ExampleProtocol {</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func move(from source: Int, to destination: Int)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func max(_ a: Int, _ b: Int) -> Int</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func find(_: String, in: String)</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>struct ExampleStruct1: ExampleProtocol {</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func move(from source: Int, to destination: Int) { return }</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func max(_ a: Int, _ b: Int) -> Int { return 0 }</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func find(_: String, in: String) { return }</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>//still conforms, despite differences to the protocol signature</span><br></blockquote><blockquote type="cite"><span>struct ExampleStruct2: ExampleProtocol {</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func move(from: Int, to: Int) { return }</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func max(_ first: Int, _ second: Int) -> Int { return 0 }</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> func find(_ substring: String, in string: String) { return }</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span>````</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>ExampleStruct2 conforms to ExampleProtocol, yet clearly has some</span><br></blockquote><blockquote type="cite"><span>differences to the signatures defined in the protocol. In</span><br></blockquote><blockquote type="cite"><span>ExampleStruct2, its `move` function has no local parameter names,</span><br></blockquote><blockquote type="cite"><span>despite their presence in the protocol definition. Its `max` function</span><br></blockquote><blockquote type="cite"><span>has differing local names, and `find` has names which aren't present</span><br></blockquote><blockquote type="cite"><span>in the protocol.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>In functions, it is the purpose of external parameter labels serve to</span><br></blockquote><blockquote type="cite"><span>add clarity to the call site. The local names become variables in the</span><br></blockquote><blockquote type="cite"><span>function's scope, and are generally invisible to the caller. While</span><br></blockquote><blockquote type="cite"><span>these local names can be declared in the protocol, they aren't</span><br></blockquote><blockquote type="cite"><span>enforced, and are effectively useless. A confused user may expect that</span><br></blockquote><blockquote type="cite"><span>this will enforce the local names, or otherwise specify a requirement,</span><br></blockquote><blockquote type="cite"><span>similar to other protocol semantics.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## Proposed solution</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Remove the ability to specify local parameter names from protocols.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## Detailed design</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Specification of local parameter names in protocols would trigger a</span><br></blockquote><blockquote type="cite"><span>compiler error, explaining that local parameter names are not</span><br></blockquote><blockquote type="cite"><span>enforced, with a fixit to remove the local name from the parameter</span><br></blockquote><blockquote type="cite"><span>list.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## Impact on existing code</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This will break existing protocols which declare local parameter</span><br></blockquote><blockquote type="cite"><span>names, but should be easily fixable with the migrator, or the</span><br></blockquote><blockquote type="cite"><span>previously mentioned fixit.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## Alternatives considered</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Leave protocols as they are now, or enforce local parameter names where specified.</span><br></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><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>-- </span><br><span>Dave</span><br><span></span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>