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-8218] Generic closure tuple argument destructuring fails #50750

Closed
swift-ci opened this issue Jul 10, 2018 · 3 comments
Closed

[SR-8218] Generic closure tuple argument destructuring fails #50750

swift-ci opened this issue Jul 10, 2018 · 3 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

@swift-ci
Copy link
Collaborator

Previous ID SR-8218
Radar None
Original Reporter Vermeulen (JIRA User)
Type Bug
Status Closed
Resolution Won't Do
Environment

Xcode 10.0 beta 3 and the Swift toolchain that comes with it

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

md5: 9ab04c1b9368b586836ed517bb28d908

Issue Description:

struct Foo<T> {}
struct Bar {}

extension Foo where T == (x: Bar, y: Bar) {
    static let foo = Foo()
}

func f<T>(_ foo: Foo<T>, _ handler: (T) -> Void) {}
f(.foo) { x, y in }  // Contextual closure type '(_) -> Void' expects 1 argument, but 2 were used in closure body

I can make this code compile in three ways:

  • replace `f(.foo)` with `f(Foo.foo)`

  • replace the static parameter with a global `let foo = Foo<(x: Bar, y: Bar)>()` (and replace `f(.foo)` with `f(foo)`)

  • remove the labels from the generic constraint, i.e. write `where T == (Bar, Bar)` instead

@belkadan
Copy link
Contributor

This is correct behavior. A function that takes one parameter of tuple type (labeled or unlabeled) is distinct from a function that takes two parameters. The other cases you mention are all source compatibility concessions where this was improperly enforced.

cc @rudkx to confirm

@rudkx
Copy link
Member

rudkx commented Jul 10, 2018

Yes that's basically right. This doesn't work in general but there are some cases where it was made to continue to work for reasons of backwards compatibility.

Long term I think it would be great to support tuple destructuring in general in parameter lists (not just closures), but that's a feature we need to design and move through the Swift Evolution process, and it's not really practical to do until we do some important clean-up related to how we represent function types and argument lists.

@belkadan
Copy link
Contributor

Ah, yes, that's SR-1620.

@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
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
Development

No branches or pull requests

3 participants