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-8821] Failure to resolve overload based on non-throwing-ness of function argument #51329

Open
swift-ci opened this issue Sep 23, 2018 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-8821
Radar rdar://problem/44728598
Original Reporter neightchan (JIRA User)
Type Bug
Environment

Version 10.0 beta 6 (10L232m)

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

md5: 24b2ac7e9bf69333e5d2a8943697b492

relates to:

  • SR-8820 Preference to resolve overload using function with closure taking-as-argument a throwing closure

Issue Description:

The following code fails to compile

public func problem(
    function: () -> Void,
    perform: (() -> Void) -> Void
)
{
    print("non-throwing")
}

public func problem(
    function: () throws -> Void,
    perform: (() throws -> Void) -> Void
)
{
    print("throwing")
}

func identity() -> Void {}

func uhoh() {
    problem(
        function: identity,
        perform: { _ in return () }
    )
}

It seems like it would be reasonable to select the overload of problem(function:perform🙂 which takes a non-throwing function as its first argument since the provided function identity does not in fact throw and the second argument

{ _ in return () }

would be valid for both overloads.

@belkadan
Copy link
Contributor

The simple case works:

func x(_: () -> Void) { print("non")}
func x(_: () throws -> Void) { print("throws") }

func y() {}
func z() throws {}

x(y)
x(z)

x { y() }
x { try z() }

so something else must be going on.

@swift-ci create

@belkadan
Copy link
Contributor

Ah…SR-8820 probably explains it.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

2 participants