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

Jump to bottom

[SR-8625] Swift should warn if a closures is passed to an argument that is an autoclosure #51140

Open
ahoppen opened this issue Aug 23, 2018 · 8 comments
Open

[SR-8625] Swift should warn if a closures is passed to an argument that is an autoclosure #51140

ahoppen opened this issue Aug 23, 2018 · 8 comments
Labels
compiler The Swift compiler in itself improvement type checker Area → compiler: Semantic analysis

Comments

@ahoppen
Copy link
Contributor

ahoppen commented Aug 23, 2018

Previous ID SR-8625
Radar rdar://problem/43656885
Original Reporter @ahoppen
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, TypeChecker
Assignee None
Priority Medium

md5: 6ab963c6a9adb6a73748b5de46042569

is duplicated by:

Issue Description:

Swift should emit a warning if a closures is passed to a parameter that is marked as @autoclosure.

Consider the following function:

func printLazy<T>(_ exp: @autoclosure () -> T) {
  print(exp())
}

This is meant to be called like

printLazy("hello")

but looking at the closure signature you may easily get the idea that you can call printLazy like

printLazy({
  return "abc"
})

The code compiles fine but the closure gets wrapped into another single statement closure that returns the passed closure, giving the output (Function) and not "abc".

I believe we should emit a warning if a closure gets passed to an argument expecting an auto closure with some way of silencing the warning (e.g. casting the closure to its own type)

Background

I hit the issue when writing a test case that contained code like the following:

XCTAssertNoThrow({
  throw MyError.theError
})

The test case did not fail because the closure was never actually executed.
@ahoppen
Copy link
Contributor Author

ahoppen commented Aug 23, 2018

@swift-ci create

@xedin
Copy link
Member

xedin commented Aug 26, 2018

This looks like a good starter bug for constraint system.

@swift-ci
Copy link
Collaborator

Comment by Suyash Shekhar (JIRA)

Is anyone working on this bug? I want to contribute to Swift and this seems like a good starting point.

@xedin
Copy link
Member

xedin commented Oct 31, 2018

sushinoya (JIRA User) Thank you for your interest, we are actually considering removing this behavior all together starting from Swift > 5, because conversions like described in the issue are not a valid behavior.

@swift-ci
Copy link
Collaborator

Comment by Suyash Shekhar (JIRA)

@xedin Sure I understand 🙂 Would you be able to recommend any easy starter bugs which I could try? I browsed through a few but since I've never contributed to Swift before so I'm unsure how difficult certain bugs are. Thanks!

@xedin
Copy link
Member

xedin commented Oct 31, 2018

Ah sure, absolutely! You can try SR-7301, SR-7113 (I'm not sure if Ray is still working on it) or SR-5819

@LucianoPAlmeida
Copy link
Collaborator

@xedin If I understand correctly, I think we just found out that this couldn't be fixed due source compatibility and also is kind of dupe of SR-12033. So we probably should resolve one of them as a dupe ...

@xedin
Copy link
Member

xedin commented Feb 19, 2021

I'd suggest we do a reverse and resolve SR-12033 as a dupe of this one, since it's an older bug.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler The Swift compiler in itself improvement type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@xedin @ahoppen @LucianoPAlmeida @swift-ci