Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-5719] Ban autoclosure forwarding #48289

Closed
DevAndArtist mannequin opened this issue Aug 20, 2017 · 6 comments
Closed

[SR-5719] Ban autoclosure forwarding #48289

DevAndArtist mannequin opened this issue Aug 20, 2017 · 6 comments
Assignees

Comments

@DevAndArtist
Copy link
Mannequin

@DevAndArtist DevAndArtist mannequin commented Aug 20, 2017

Previous ID SR-5719
Radar rdar://problem/37321597
Original Reporter @DevAndArtist
Type Bug
Status Resolved
Resolution Done
Environment

Xcode 8.3.3

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee @DevAndArtist
Priority Medium

md5: 401a3fa1c8f5f08e5385cee515f04b79

is duplicated by:

Issue Description:

func autoclosureFoo(_ c: @autoclosure () -> Int) {
    print(c())
}

func autoclosureBar(_ c: @autoclosure () -> Int) {
    autoclosureFoo(c) // <-- This one here
    autoclosureFoo(c())
}

func baz(_ c: () -> Int) {
    autoclosureFoo(c) // does not work as expected
}

autoclosureBar(42)

If this requires a full review on the evolution side, let me know, I'll start a new thread.

@CodaFi
Copy link
Member

@CodaFi CodaFi commented Aug 21, 2017

Oh dear. This seems to have been the result of a bad conditional left over when fixing SR-832.

@CodaFi
Copy link
Member

@CodaFi CodaFi commented Aug 23, 2017

To expand: The rules for matching parallel @autoclosure function types are

  • If doing a conversion, strip off the Void input from the second type and recur matching the result against the first type.

  • If doing equality, try parallel matches. Both types must have @autoclosure to do so.

The condition in SR-832 instead checks for a mismatch and uses that as evidence it is doing a conversion which, being the identity, succeeds trivially. I'm not sure we can cut this off without severely breaking source (naive fix I have for this indicates that XCTest and Foundation are relying on this).

@DevAndArtist
Copy link
Mannequin Author

@DevAndArtist DevAndArtist mannequin commented Aug 23, 2017

Yet it's an abuse of a bug, similar like some people abuse

guard let `self` = self else { ... }

in closures with `weak` self.

I see two options (there is third one, but I won't be happy with it in a long term):

  1. Fix this issue (provide migration for this `add () at the ende of the forwarded autoclosure`)

  2. Align autoclosure with normal closures to accept normal explicit closures with the same signature (however this might have breaking changes in generic area - if I'm wrong here, then this change is more than welcome)

func foo() -> Int { return 42 }
func bar(_ c: @autoclosure () -> Int) { ... }
bar(foo) 

This would allow us to specify autoclosures with default reference to another function/closure:

func foo() -> Int { return 42 }
func bar(_ c: @autoclosure () -> Int = foo) { ... }
bar() 

3. Live with this asymmetric bug.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Aug 28, 2017

I think it does need to go to swift-evolution, since it will break existing code. A core team member could rule that it doesn't need a full review, but it should at least come up there.

@xedin
Copy link
Member

@xedin xedin commented Feb 7, 2018

@swift-ci create

@xedin
Copy link
Member

@xedin xedin commented Dec 13, 2018

@autoclosure forwarding has been banned starting from `swift-version 5`.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants