So, local names give you a way to refer to specific arguments? Fair enough.
On the other point I mentioned, is there any particular reason local names show up in autocomplete, but only for certain parameters (ones wihout labels)? I'd like to hear the reasoning for this rule. On the surface at least, it seems inconsistent.
------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <m2fur58dn8.fsf@fripp.apple.com>
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.
···
on Tue Jul 19 2016, James Froggatt <swift-evolution@swift.org> wrote:
## Motivation
Consider the following code:
protocol ExampleProtocol { func move(from source: Int, to destination: Int) func max(_ a: Int, _ b: Int) -> Int func find(_: String, in: String) } struct ExampleStruct1: ExampleProtocol { func move(from source: Int, to destination: Int) { return } func max(_ a: Int, _ b: Int) -> Int { return 0 } func find(_: String, in: String) { return } } //still conforms, despite differences to the protocol signature struct ExampleStruct2: ExampleProtocol { func move(from: Int, to: Int) { return } func max(_ first: Int, _ second: Int) -> Int { return 0 } func find(_ substring: String, in string: String) { return } }
ExampleStruct2 conforms to ExampleProtocol, yet clearly has some
differences to the signatures defined in the protocol. In
ExampleStruct2, its `move` function has no local parameter names,
despite their presence in the protocol definition. Its `max` function
has differing local names, and `find` has names which aren't present
in the protocol.In functions, it is the purpose of external parameter labels serve to
add clarity to the call site. The local names become variables in the
function's scope, and are generally invisible to the caller. While
these local names can be declared in the protocol, they aren't
enforced, and are effectively useless. A confused user may expect that
this will enforce the local names, or otherwise specify a requirement,
similar to other protocol semantics.## Proposed solution
Remove the ability to specify local parameter names from protocols.
## Detailed design
Specification of local parameter names in protocols would trigger a
compiler error, explaining that local parameter names are not
enforced, with a fixit to remove the local name from the parameter
list.## Impact on existing code
This will break existing protocols which declare local parameter
names, but should be easily fixable with the migrator, or the
previously mentioned fixit.## Alternatives considered
Leave protocols as they are now, or enforce local parameter names where specified.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
ºÀ
------------- End Message -------------
From James F