On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution < [email protected]> wrote:
> > 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. > Would the future directions given in SE-0111 be appropriate for consideration in the current phase of Swift 4 evolution, or would they be irrelevant to the ABI? > > - Doug > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
