[swift-dev] SE-0111 related question
Benjamin G
benjamin.garrigues at gmail.com
Thu Aug 18 11:52:50 CDT 2016
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 ?
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 ? 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.
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 ?
callback( nil, nil, nil, request) isn't really pleasant to read compared to
callback(data:nil, error:nil, info:nil, request: request)
Sorry again if i'm reopening a settled discussion, but once again me and
the people i'm working with all had trouble understanding the rational
behind the changes induced in our code.
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160818/4cded94c/attachment.html>
More information about the swift-dev
mailing list