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.

Sign up for GitHub

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-5202] Another Swift 4.0 regression regarding tuple decomposition in closures #47778

Closed
NachoSoto opened this issue Jun 12, 2017 · 12 comments
Closed

[SR-5202] Another Swift 4.0 regression regarding tuple decomposition in closures #47778

NachoSoto opened this issue Jun 12, 2017 · 12 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@NachoSoto
Copy link
Contributor

Previous ID SR-5202
Radar None
Original Reporter @NachoSoto
Type Bug
Status Resolved
Resolution Done
Environment

Swift version 4.0 (swiftlang-900.0.43 clang-900.0.22.8)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: e2a4b0b15d704b35cd7e884fe2a5d914

Issue Description:

struct F<T> {
    func map<R>(a: (T) -> R) {}
}

This used to compile in Swift 3.x:

F<Void>().map { return 0 }

But now fails with a very silly error IMO:

error: repl.swift:5:15: error: contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
F<Void>().map { return 0 }
              ^
                _ in

Why would I want to explicitly ignore Void?
@belkadan
Copy link
Contributor

cc @slavapestov, @rudkx

@belkadan
Copy link
Contributor

The empty tuple is a value regardless of whether you care about it or not.

@belkadan
Copy link
Contributor

(Which isn't to say it isn't worth special-casing. It's just that it would be a special case.)

@NachoSoto
Copy link
Contributor Author

Sure, but honestly I think the previous behavior made more sense.

@NachoSoto
Copy link
Contributor Author

> (Which isn't to say it isn't worth special-casing. It's just that it would be a special case.)

Makes sense

@NachoSoto
Copy link
Contributor Author

So any updates on this regression?

@belkadan
Copy link
Contributor

Oops. It was "fixed" when we rolled back most of SE-0110. It should be working now.

@NachoSoto
Copy link
Contributor Author

Are there regression tests for this though?

@belkadan
Copy link
Contributor

@rudkx?

@NachoSoto
Copy link
Contributor Author

Specifically I mean not needing `_ in` for a closure that takes a `Void` parameter.

@rudkx
Copy link
Member

rudkx commented Aug 29, 2017

I couldn't find anything specifically testing that, so: #11674

@NachoSoto
Copy link
Contributor Author

Awesome, thank you!

@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
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rudkx @NachoSoto @belkadan