[swift-evolution] Disallow local parameter names in protocols

[Karl]

> On 20 Jul 2016, at 00:30, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Tue Jul 19 2016, James Froggatt <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> Made a draft proposal to start this discussion, and help define the
>> problem. I'm not too biased either way, this isn't a particularly
>> major aspect of the language, but obviously the proposal has to
>> justify the potential change to the language. This is something due
>> for re-evaluation since Swift 3 removed the ‘first-argument
>> hide-by-default’ rule, which now makes this simplification possible.
>> 
>> Hoping to get an idea of what people's opinions are on this, and the
>> subject of local parameter names leaking to the user in
>> general. Please let me know if my reasoning is flawed, anywhere.
>> 
>> ## Introduction
>> 
>> Swift's current treatment of local parameter names is rather
>> odd. They're hidden from the caller most of the timer, where an
>> external parameter label is specified, but otherwise (if a ‘_’ is
>> used), they actually leak out into Xcode's autocomplete. External
>> labels are intended to add clarity, so the local names seem like they
>> should be an implementation detail. Otherwise, why don't local names
>> show up for labelled parameters, too?
>> 
>> The main point in the language affected by this ambiguity is in the
>> protocol definition, where local names can be specified, but are only
>> in any way useful for autocomplete when implementing the protocol,
>> making them useless to the language itself. 
> 
> They're useful in documentation comments, which you might have realized
> if you had included them in your examples ;-)
> 
>> This proposal, if accepted, would simplify the language by removing
>> the ability to declare local parameter names from protocols, reducing
>> their function signatures to just the actual requirements - label and
>> type.
> 
> Code completion and doc comments are good enough reasons (for me) to
> keep this capability.  I am opposed to any change here.


Ditto. That’s what I use them for.

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160720/c2236690/attachment.html>