Repository navigation
[SR-2008] Implement SE-0110: Distinguish between single-tuple and multiple-argument function types #44617
Description
| 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
Activity
dduan commentedon Aug 1, 2016
Part I (disallow multi-argument to tuple coercion) implemented: #3895
swift-ci commentedon Aug 8, 2016
Comment by Paul Meng (JIRA)
An attempt to implement the full SE-0110: #4102
jtbandes commentedon Aug 18, 2016
PaulMeng (JIRA User), is this done?
swift-ci commentedon Aug 18, 2016
Comment by Paul (JIRA)
Yes. It's merged.
swift-ci commentedon Aug 18, 2016
Comment by Paul Meng (JIRA)
Uh, sorry. Logged-in with the wrong account. It's merged.
DougGregor commentedon Sep 24, 2016
This is done, but didn't make it into Swift 3
swift-ci commentedon Sep 24, 2016
Comment by Alex Martini (JIRA)
The implementation was reverted:
f42158b
swift-ci commentedon Sep 26, 2016
Comment by Paul Meng (JIRA)
Let me look into it and propose a fix.
swift-ci commentedon 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 commentedon Nov 14, 2016
apple/swift#3895 was reverted by apple/swift#3922 (aka apple/swift@f42158b).
apple/swift#4102 has not been reverted yet.
DougGregor commentedon Nov 14, 2016
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 commentedon Dec 26, 2016
Comment by Fabian Ehrentraud (JIRA)
Will this fix SR-2135 too?
slavapestov commentedon Dec 30, 2016
I implemented this on master in this PR: #6133
swift-ci commentedon Mar 9, 2017
Comment by Raphael (JIRA)
It is not clear to me from the SE if
benrimmington commentedon Mar 10, 2017
@reitzig (JIRA User): I think it would be an error in
-swift-version 4mode:swift/test/Constraints/tuple_arguments.swift
Should we require parentheses in closure expression parameter lists?
Tuple Destructuring in Parameter Lists
swift-ci commentedon Mar 12, 2017
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)) -> Voidfrom(X,Y,Z) -> Voidin 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 commentedon Mar 12, 2017
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 commentedon Mar 12, 2017
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)) -> VoidI'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 commentedon Jun 21, 2017
Mark Lacey has merged:
apple/swift#10027 (master)
apple/swift#10414 (swift-4.0-branch)