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

Jump to bottom

[SR-9312] Confusing error when indirectly returning in map #51782

Closed
BasThomas opened this issue Nov 21, 2018 · 4 comments
Closed

[SR-9312] Confusing error when indirectly returning in map #51782

BasThomas opened this issue Nov 21, 2018 · 4 comments
Assignees
@BasThomas
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation type checker Area → compiler: Semantic analysis

Comments

@BasThomas
Copy link
Contributor

Previous ID SR-9312
Radar rdar://problem/52193383
Original Reporter @BasThomas
Type Bug
Status Resolved
Resolution Done
Environment

version 4.2 (swiftlang-1000.11.37.1 clang-1000.11.45.1)

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

md5: a5be35bd52850917462d3f2f05995f74

Issue Description:

When mapping over a value that is a tuple, indirectly returning it will create a confusing / incorrect error.

Imagine the following code:

let tupleArray = [("hello", "world")]
let tValues = tupleArray.map { _, value in
    let v = value
    return v
}

The following error appears on line 2:

Closure tuple parameter '(String, String)' does not support destructuring
Replace '_, value in
    ' with '(arg) in
    
    let (_, value) = arg
    '

Using the fixit, we will then get this code, that produces the actual, expected error... and another, less expected one:

let tupleArray = [("hello", "world")]
let tValues = tupleArray.map { (arg) in // Unable to infer complex closure return type; add explicit type to disambiguate

    let (_, value) = arg // Type of expression is ambiguous without more context
    let v = value
    return v
}

The second error is unexpected.

Both can be fixed by explicitly using a return type:

let tupleArray = [("hello", "world")]
let tValues = tupleArray.map { (arg) -> String in

    let (_, value) = arg
    let v = value
    return v
}

... but we could've done that in the first place, using destructuring:

let tupleArray = [("hello", "world")]
let tValues = tupleArray.map { _, value -> String in
    let v = value
    return v
}
@belkadan
Copy link
Contributor

Another "destructuring-is-barely-supported-but-we-couldn't-get-rid-of-it" bug for @xedin and @rudkx.

@xedin
Copy link
Member

xedin commented Nov 26, 2018

I remember @rudkx made a change so de-structuring like that is still supported for trailing closures, we just need to get error message to point out that result type has to be specified in this case because it can't be inferred...

@xedin
Copy link
Member

xedin commented Nov 26, 2018

@swift-ci create

@xedin
Copy link
Member

xedin commented Mar 17, 2020

Looks like with Xcode 11.4 only error diagnostic compiler would produce is:

```
error: unable to infer complex closure return type; add explicit type to disambiguate
let tValues = tupleArray.map { _, value in
^
-> <#Result#>

```

Unfortunately this is the way multi-statement closures are type-checked because `map` returns a generic parameter type and body of the closure is not included in type-check of outer expression it’s impossible to figure out what result type is supposed to be. Destructuring error has fixed.

Please use Xcode 11.4 beta or snapshot of the master compiler to verify.

@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

@BasThomas BasThomas

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@xedin @belkadan @BasThomas