[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