[swift-evolution] [swift-dev] SE-0111 related question

[Xiaodi Wu]

On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev <swift-dev at swift.org>
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160818/cf33f5c5/attachment.html>