> On 20 Jul 2016, at 00:30, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
>
> on Tue Jul 19 2016, James Froggatt <[email protected]
> <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
