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

[Concurrency] Tune overloading to to allow sync overloads in async contexts #36247

Merged

Conversation

DougGregor
Copy link
Member

@DougGregor DougGregor commented Mar 3, 2021

The existing overloading rules strongly prefer async functions within
async contexts, and synchronous functions in synchronous contexts.
However, when there are other differences in the
signature, particularly parameters of function type that differ in
async vs. synchronous, the overloading rule would force the use of the
synchronous function even in cases where the synchronous function
would be better. An example:

func f(_: (Int) -> Int) { }
func f(_: (Int) async -> Int) async { }

func g(_ x: Int) -> Int { -x }

func h() async {
  f(g) // currently selects async f, want to select synchronous f
}

Effect the semantics change by splitting the "sync/async mismatch"
score in the constraint system into an "async in sync mismatch" score
that is mostly disqualifying (because the call will always fail) and a
less-important score for "sync used in an async context", which also
includes conversion from a synchronous function to an asynchronous
one. This way, only synchronous functions are still considered within
a synchronous context, but we get more natural overloading behavior
within an asynchronous context. The end result is intended to be
equivalent to what one would get with reasync:

func f(_: (Int) async -> Int) async { ... }

Addresses rdar://74289867.

…ntexts.

The existing overloading rules strongly prefer async functions within
async contexts, and synchronous functions in synchronous contexts.
However, when there are other differences in the
signature, particularly parameters of function type that differ in
async vs. synchronous, the overloading rule would force the use of the
synchronous function even in cases where the synchronous function
would be better. An example:

    func f(_: (Int) -> Int) { }
    func f(_: (Int) async -> Int) async { }

    func g(_ x: Int) -> Int { -x }

    func h() async {
      f(g) // currently selects async f, want to select synchronous f
    }

Effect the semantics change by splitting the "sync/async mismatch"
score in the constraint system into an "async in sync mismatch" score
that is mostly disqualifying (because the call will always fail) and a
less-important score for "sync used in an async context", which also
includes conversion from a synchronous function to an asynchronous
one. This way, only synchronous functions are still considered within
a synchronous context, but we get more natural overloading behavior
within an asynchronous context. The end result is intended to be
equivalent to what one would get with reasync:

  func f(_: (Int) async -> Int) async { ... }

Addresses rdar://74289867.
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

@swift-ci please test source compatibility

@DougGregor DougGregor merged commit 5552a4b into apple:main Mar 3, 2021
@DougGregor DougGregor deleted the async-sync-overloading-like-reasync branch March 3, 2021 15:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant