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

Named opaque result types #40715

Merged
merged 4 commits into from Jan 5, 2022
Merged

Conversation

DougGregor
Copy link
Member

@DougGregor DougGregor commented Dec 30, 2021

Implement support for named opaque result types, e.g.,

func f() -> <T: Hashable & P, U where U: Q> [T: U] { ... }

this mostly involves wiring up name lookup and type resolution so we can find the generic parameters
when they are used.

@DougGregor
Copy link
Member Author

@swift-ci please test

@swift-ci
Copy link
Collaborator

Build failed
Swift Test Linux Platform
Git Sha - a82efca885e305910473c758c0c29122258f96dd

@DougGregor
Copy link
Member Author

@swift-ci please smoke test

2 similar comments
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

@swift-ci please smoke test

Address small gaps in several places to make named opaque result types
partially work:

* Augment name lookup to look into the generic parameters when inside the
result type, which is used both to create structure and add requirements
via a `where` clause.
* Resolve opaque generic type parameter references to
OpaqueTypeArchetypeType instances, as we do for the "some" types
* Customize some opaque-type-specific diagnostics and type printing to
refer to the opaque generic parameter names specifically
* Fix some minor issues with the constraint system not finding
already-opened opaque generic type parameters and with the handling of
the opaque result type candidate set.

The major limitation on opaque types, where we cannot add requirements
that aren't strictly protocol or superclass requirements on the
generic parameters, remains. Until then, named opaque result types are
no more expressive than structural opaque result types.
Add lookup scopes for the generic parameters of a named opaque result
type and clean up the code that finds the opaque substitutions.
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

There's a bunch more work to do, but most of the hard part is representational changes that have little to do with named opaque result types, but need this to properly test. Merging now, since everything is still behind a flag.

@DougGregor DougGregor merged commit 40fff9c into apple:main Jan 5, 2022
@DougGregor DougGregor deleted the named-opaque-result-types branch January 5, 2022 17:10
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

2 participants