I have thought of this before, but I always got stuck on the problem of nested 
closures.
Imagine you’re calling a function that takes an auto closure inside another 
closure.
What exactly will `$0` refer to?

> On Jun 24, 2017, at 7:10 PM, Adrian Zubarev via swift-evolution 
> <[email protected]> wrote:
> 
> Hello folks,
> 
> Here is a quick and straightforward pitch about @autoclosure. Currently the 
> attribute indicates that the caller has to pass an expression so that the 
> braces can be omitted. This is a convenient behavior only, but it also has 
> it’s shortcomings.
> 
> I would like to propose an extension of that behavior.
> 
> 
> 1. Allow access to arguments and shorthand argument names:
> // Bug: https://bugs.swift.org/browse/SR-5296 
> <https://bugs.swift.org/browse/SR-5296>
> func foo(_ test: @autoclosure (Int) -> Int = { $0 }) {
>     print(test(42))
> }
> 
> // Convenient access using shorthand arguments
> foo(Int(Double($0) * 3.14)))
> 
> 2. Make @autoclosure only wrap when necessary:
> func bar(_ test: @autoclosure () -> Int) {
>     print(test())
> }
> 
> let test = { 42 }
> 
> // function produces expected type 'Int'; did you mean to call it with '()'?
> bar(test)
> 
> 3. Extend @autoclosure to closure types in general (this change is for 
> consistent alignment):
> // Note how we're using the shorthand argument list for this expression
> let uppercaseWrapper: @autoclosure (String) -> String = $0.uppercased()
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to