> On Aug 18, 2016, at 11:17 AM, Xiaodi Wu <[email protected]> wrote:
>
> On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev <[email protected]
>> <mailto:[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?
They don’t have ABI impact, so they’d be the in “stage 2” bucket for Swift 4.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
