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-5203] Another useless diagnostic regarding type inference and closures #47779

Closed
NachoSoto opened this issue Jun 12, 2017 · 2 comments
Closed
Assignees
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

@NachoSoto
Copy link
Contributor

Previous ID SR-5203
Radar None
Original Reporter @NachoSoto
Type Bug
Status Resolved
Resolution Done
Environment

Swift version 4.0 (swiftlang-900.0.43 clang-900.0.22.8)

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

md5: ce9765cd41942faff8b14cc95e518de7

Issue Description:

struct S<A> {
    init(a: A) {
        self.a = a
    }

    private let a: A

    static func m(_ x: [S<A>]) -> S<A> {
        return x.first!
    }
}

extension S {
    func map<B>(_ f: (A) -> B) -> S<B> {
        // Is this another bug? This doesn't compile without the explicit <B>
        return S<B>(a: f(self.a))
    }
}

func f() -> S<Bool> {
    let x1 = S<Void>(a: ())
    let x2 = S<Void>(a: ())

    return S.m([
        x1.map { true },
        x2.map { false }
    ])
}
error: repl.swift:24:14: error: expression type '([S<_>]) -> S<_>' is ambiguous without more context
    return S.m([
           ~~^

Spoiler alert: what's missing is _ in in the closures. See SR-5202 for why I think that's dumb, though. But for this bug I'm focusing on how terrible the diagnostic is.

See also SR-5198 where I mention that this is not an isolated case. Diagnostics are never reliable for anything that's not a single simple expression.

@belkadan
Copy link
Contributor

cc @xedin

@xedin
Copy link
Member

xedin commented Feb 6, 2020

As of 11.4b1 this has been fixed. I had to change `S<Void>` to `S<Q>` where `struct Q {}` because `Void` no longer requires `_ in` but using `Q` did actually produce correct diagnostics for both closures:

error: contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
        x1.map { true },
               ^
                 _ in
error: contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
        x2.map { false }
               ^
                 _ in

@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 diagnostics QoI Bug: Diagnostics Quality of Implementation type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants