> On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev <[email protected]>
> wrote:
>
> Sorry for mentioning this issue again, as it seems to have been already much
> discussed, but i've had the unfortunate experience of dealing with the
> consequences of this proposal in my code since xcode beta 6, which i really
> can't get my head around.
>
> Could someone explain what is the rational behind the choice of having
> parameter names prohibited for closures but compulsory for functions ?
>
> As a software developper (and not a language expert), I would have hoped to
> get functions behave as close to closures as possible.
>
> aka :
>
> func myAdd(a : Int, b: Int) -> Int
> myAdd(a: 1 , b :2 ) -- OK
>
> vs
>
> let myAdd = (_ a: Int, _ b: Int) -> Int
> myAdd (a:1, b: 2) -- not ok still ?
This is a topic for swift-evolution; adding swift-evolution, and BCC’ing
swift-dev.
>
> After having read the argument that "parameter names are part of the function
> names, and not its type", i'm convinced that the whole proposal makes sense.
> However i can't get my head around that specific line of the proposal :
> "If the invocation refers to a value, property, or variable of function type,
> the argument labels do not need to be supplied. It will be an error to supply
> argument labels in this situation."
>
> Why make it an error in case of closures ?
A closure is an expression that creates an anonymous function, hence there is
no place to put the argument labels.
> If we agree that parameter are part of the name, then it should behave just
> like a name. Specifying names shouldn't matter more than the name of the
> variable storing the closure. It seems to me, humbly, that the fact that part
> of the name is split and written closer to the parameters could be considered
> just as syntactic sugar.
We could invent a language extension there. The point of requiring the
underscores in:
let myAdd: (_ a: Int, _ b: Int) -> Int
Is to allow for some future evolution here. IIRC, it was discussed in the
review thread, that we could imagine ‘let’s with compound names, e.g.,
let myAdd(a:b:): (Int, Int) -> Int
Or perhaps allow syntactic sugar such as
let myAdd: (a: Int, b: Int) -> Int
To be the same thing. Again, this is future language extensions.
> Another hint that something's wrong : the proposal still lets the possibility
> to specify names in type declarations for documentation purpose, using "_" .
> But then why not let us specify those names at call site too ?
Because they are parameter names, not argument labels. If you declare a
function with parameter names but not argument labels:
func f(_ a: Int) { }
You *cannot* specify argument labels at the call site:
f(a: 1) // error: first argument is unlabeled
> callback( nil, nil, nil, request) isn't really pleasant to read compared to
> callback(data:nil, error:nil, info:nil, request: request)
This was a known issue with the Swift 3 change, and there are (known) possible
future language directions to bring back some of this. We focused on fixing the
type system oddities first in Swift 3 (that’s the breaking part) and can
consider improvements in the future.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
