Open swift-ci opened 7 years ago
@slavapestov, I thought we managed to destroy these? I do see the errors in Swift 4 mode.
Do or don't see the errors in Swift 4 mode?
it behaves as expected for me:
tup.swift:7:19: error: extra argument in call
var odd = test(1, 2)
^
tup.swift:9:28: error: extra argument 'b' in call
var labels = test(a: 1, b: 2)
^
Marco, in Swift 3, the proposal to disambiguate argument lists from tuple arguments (SE-0110) was not fully implemented. On master (you can try the latest snapshot if you want), enabling Swift 4 mode will make the suspect cases into type errors.
Comment by Marco von Ballmoos (JIRA)
@slavapestov: Thanks for the tip about Swift 4 mode. I have a workaround for it, but wanted to report the bug in case you weren't aware of it. Thanks for the quick responses!
Attachment: Download
Environment
XCode Version 8.2.1 (8C1002), MacOS 10.12.3 (16D32)Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: f458cd138c0b5cd9ccfb13befee8169dIssue Description:
The following code compiles and yields somewhat unexpected results.
Here are the results in the Playground:
With argument label looks fine:
Without argument label seems strange:
odd: Swift interpreted the two parameters as a Tuple. Is that correct, though? Are the parentheses allowed to serve double-duty both as part of the function-call expression and as part of the tuple expression?
labels: The issue with double-duty parentheses isn’t limited to anonymous tuples. The compiler treats what looks like two labeled function-call parameters as a tuple with two Ints labeled {a:} and {b:}.
nestedTuple: This is not a tuple of a tuple, but just a two-element tuple
I wrote up more details on my blog before I discovered that this issue-tracker for Swift.