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-2008] Implement SE-0110: Distinguish between single-tuple and multiple-argument function types #44617

Closed
lattner mannequin opened this issue Jul 7, 2016 · 19 comments
Assignees
Labels
compiler The Swift compiler in itself good first issue Good for newcomers task

Comments

@lattner
Copy link
Mannequin

lattner mannequin commented Jul 7, 2016

Previous ID SR-2008
Radar rdar://problem/27383557
Original Reporter @lattner
Type Task
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Task, StarterBug
Assignee @slavapestov
Priority Medium

md5: 83ce6240317526d0237e3fdd515173d3

relates to:

  • SR-2135 Multiple Tuple Parameters to a Closure cannot be Decomposed in the Parameter List

Issue Description:

SE-0110 has been accepted, we just need an implementation!
https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

@dduan
Copy link
Collaborator

dduan commented Aug 1, 2016

Part I (disallow multi-argument to tuple coercion) implemented: #3895

@swift-ci
Copy link
Collaborator

swift-ci commented Aug 8, 2016

Comment by Paul Meng (JIRA)

An attempt to implement the full SE-0110: #4102

@jtbandes
Copy link
Collaborator

PaulMeng (JIRA User), is this done?

@swift-ci
Copy link
Collaborator

Comment by Paul (JIRA)

Yes. It's merged.

@swift-ci
Copy link
Collaborator

Comment by Paul Meng (JIRA)

Uh, sorry. Logged-in with the wrong account. It's merged.

@DougGregor
Copy link
Member

This is done, but didn't make it into Swift 3

@swift-ci
Copy link
Collaborator

Comment by Alex Martini (JIRA)

The implementation was reverted:

f42158b

@swift-ci
Copy link
Collaborator

Comment by Paul Meng (JIRA)

Let me look into it and propose a fix.

@swift-ci
Copy link
Collaborator

swift-ci commented Oct 6, 2016

Comment by Greg Lutz (JIRA)

I was hoping that the implementation of SE-0110 would end up fixing SR-1795, but I'm not so sure it will. The point is, if single-tuple and multiple-argument functions are distinguishable, they'd damn well better mangle to different names! So they can, for example, co-exist in the same module.

@benrimmington
Copy link
Collaborator

apple/swift#3895 was reverted by apple/swift#3922 (aka apple/swift@f42158b).

apple/swift#4102 has not been reverted yet.

@DougGregor
Copy link
Member

The SE-0110 implementation on master is a bit of a mess right now. SE-0110 is partially implemented, but doesn't restrict all of the cases it should restrict, and doesn't provide backward compatibility in the Swift 3 compatibility mode.

@swift-ci
Copy link
Collaborator

Comment by Fabian Ehrentraud (JIRA)

Will this fix SR-2135 too?

@slavapestov
Copy link
Member

I implemented this on master in this PR: #6133

@swift-ci
Copy link
Collaborator

swift-ci commented Mar 9, 2017

Comment by Raphael (JIRA)

It is not clear to me from the SE if

@benrimmington
Copy link
Collaborator

@swift-ci
Copy link
Collaborator

Comment by Raphael (JIRA)

@benrimmington I don't see how links 2,3 are related?

I see that the issue would be to distinguish ((X,Z,Y)) -> Void from (X,Y,Z) -> Void in the literal. I guess my proposal/expectation is that { (x,y,z) in ... } always have the former type, and { x, y, z in ... } always have the latter, and that both versions are the only way to express their respective type (without explicit type annotations, that is).

In particular, {{{ (x,y,z) in ... } }} should never match a multi-parameter function type. If I understand correctly, currently both literals would infer to the multi-parameter type, which causes the confusion and, I daresay, inconsistency.

@benrimmington
Copy link
Collaborator

You're proposing two changes:

  • tuple destructuring in parameter lists (which is currently not supported);

  • and for closure expressions, disallowing single parentheses around multiple parameters, or requiring double parentheses for tuple destructuring.

@swift-ci
Copy link
Collaborator

Comment by Raphael (JIRA)

I guess I am.

One could be ambitious and propose general destructuring (similar to Scala). By using a keyword, backwards-compatibility and unambiguity could be achieved.

Example: { let (x,y,z) in ...} : ((X,Y,Z)) -> Void

I'm not sure which Swift types can be destructured. In addition to typles, enums probably, but that would make little sense in a closure parameter list, except if we could move the case there:

@benrimmington
Copy link
Collaborator

Mark Lacey has merged:

@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
compiler The Swift compiler in itself good first issue Good for newcomers task
Projects
None yet
Development

No branches or pull requests

6 participants