Skip to content

Sema: don't consider opaque types distinct for overloading purposes. #24166

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

Merged
merged 1 commit into from
Apr 26, 2019

Conversation

jckarter
Copy link
Contributor

This is necessary because:

func foo() -> some P
func foo() -> some P

theoretically defines two distinct return types, but there'd be no way to disambiguate them. Disallow overloading only by opaque return type.

@jckarter
Copy link
Contributor Author

@swift-ci Please smoke test

lib/AST/Decl.cpp Outdated
// Replace an opaque archetype with a common dummy type. Functions and
// subscripts cannot overload differing only in opaque return types.
if (type->getAs<OpaqueTypeArchetypeType>()) {
type = BuiltinIntegerType::get(0x12345678u, ctx);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would erasing to the existential type be better? I'm worried this might leak through in diagnostics

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. That would mean that you couldn't overload:

func foo() -> any P
func foo() -> some P

I was also trying to prevent:

func foo() -> some P
func foo() -> some Q

since there would still be no way to disambiguate these.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn’t the latter be disambiguated by calling a generic function with a T: P or T: Q constraint with foo() as an argument?

IIRC the redeclaration checking uses a tuple of flags in addition to the erased overload type as the unique key. You could add a HasOpaqueResult flag and erase to an existential.

This is necessary because:

```
func foo() -> some P
func foo() -> some P
```

theoretically defines two distinct return types, but there'd be no way to disambiguate them. Disallow overloading only by opaque return type.
@jckarter jckarter force-pushed the opaque-overload-checking branch from b333568 to b2d50c8 Compare April 25, 2019 21:29
@jckarter
Copy link
Contributor Author

@swift-ci Please smoke test

@jckarter jckarter merged commit 72701a1 into swiftlang:master Apr 26, 2019
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.

2 participants