[swift-evolution] [Idea] Custom default names for arguments of closures
Alexey Demedetskiy
dalog at me.com
Sat Feb 13 14:57:10 CST 2016
Great idea!
But I see little problem here.
In regular functions parameters names are written near their usage. $0 are also all-known. So you don’t need to ‘guess’ parameter name.
But if we will introduce some closure typealias in one file, and will use it in another - then we need somehow to know this parameter name.
Also, if closure definition will change parameters names for some reason - all client code need to be updated.
As an alternative solution, IDE hints can include these parameter names in closure autocomplete.
For your example:
executeClosure { *first, second in <#code#>* }
where *…* is a content of an autocomplete hint.
But I like the general direction anyway.
> Right now Swift provides shorthand argument names ($0, $1 etc) by default which could be overriden with more specific names. I think it would be nice to define our own default names as part of type definition:
>
> typealias Closure = (first one: String, second two: String) ->Void
>
> func executeClosure(closure: Closure) {
> // the caller uses external parameter names, nothing changed here
> closure(first: "first", second: 2)
> }
>
> executeClosure {
> // the callee uses custom arguments instead of $0, $1
> // also it is possible to override these names here as usual
> print("one \(one) two \(two)")
> }
>
> This feature is backward compatible in that way what both
>
> typealias Closure = (first: String, second: String) ->Void
>
> and
>
> typealias Closure = (String, String) ->Void
>
> will provide the same behavior like now.
>
> Possible applications: providing default argument names more meaningfull than $0, $1, DSL-like constructions.
>
> Possible problem: names could overlap. Nothing new. $0, $1 could overlap too. Override argument names or variable names in a scope._______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
More information about the swift-evolution
mailing list