[swift-evolution] [Pitch] Extending [at]autoclosure

[Gor Gyolchanyan]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170625/c5aea36c/attachment.html>