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

Adrian Zubarev adrian.zubarev at devandartist.com
Fri Jun 30 03:48:35 CDT 2017

Well as Jordan Rose said on the linked SR, option (1) will probably never happen. Option (3) only makes sense if all of the options are supported (in that case there wouldn’t be any need for explicit @autoclosure, which could simply be merged into the closure type), or (2) is NOT supported so that one could pass a default autoclosure.

It leaves us only with (2), which is potentially a (small) breaking change, but it also feels more like a fix. I cannot imagine anyone is wrapping whole closures with auto closure, nor do I think a ‘convenience’ operation should disable the explicit ability to pass in a closure with the same signature. The latter feels like a bug. Furthermore I think most code that relies on this is already doing something like.

func bar(_ closure: @autoclosure () -> Int) { foo(closure)}

func foo(_ closure: () -> Int)
But this is only an assumption of mine.

Theoretically it suppose to work the other way around, right? Again @autoclosure supposed to be a syntactical convenience feature which implies that it won’t disable *too* much from the closure type. Disallowing arguments is logical consequence but not the other issues I mentioned here and in the SR.


One question: Do we need to go through a full evolution process for pitch (2) or is a bug report enough here?

Adrian Zubarev
Sent with Airmail

Am 30. Juni 2017 um 00:59:45, Beta (rwidmann at apple.com) schrieb:

These are all interesting ideas at first blush, but introduce some oddities into the type system

1. We accept this 😳.  If we were to take this as an official language change it would mean that we would allow coercing T to (_) -> T by emitting a closure that takes an argument list (of arity given by the contextual type) that we throw away anyways.  I would much prefer we diagnose this instead.  @autoclosure is a syntactically convenient way to ask for laziness - that’s it.

2. Doing this collapses overloads on @autoclosure

func foo(_ f : @autoclosure () -> String) {}
func foo(_ f : () -> String) {}

Which is fine by me except for the code you would break that relies on this.  I don’t see a reasonable migration path here - perhaps you have one in mind.

3. @autoclosure is a parameter attribute.  Allowing it to appear in other positions is redundant and doesn’t actually accomplish anything outside of maintaining consistency with the first point.

I hope I don’t come off as too harsh.  It’s just a little shocking to me that we accept the code in the linked SR.

~Robert Widmann

On Jun 24, 2017, at 9:10 AM, 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
func foo(_ test: @autoclosure (Int) -> Int = { $0 }) {

// Convenient access using shorthand arguments
foo(Int(Double($0) * 3.14)))

2. Make @autoclosure only wrap when necessary:
func bar(_ test: @autoclosure () -> Int) {

let test = { 42 }

// function produces expected type 'Int'; did you mean to call it with '()'?

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

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

More information about the swift-evolution mailing list