Skip to content

Introduce @lifetime attribute to specify lifetime dependence on function declarations #76256

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 5 commits into from
Sep 11, 2024

Conversation

meg-gupta
Copy link
Contributor

@meg-gupta meg-gupta commented Sep 4, 2024

This implements an alternate way to specify lifetime dependence as described here - https://github.com/swiftlang/swift-evolution/blob/9ba7a574d1557eefb4bc3cce1d07efee51861f21/proposals/NNNN-lifetime-dependency.md#lifetime-annotation

rdar://134975439

TODO: Support lifetime dependence on parameter and self targets

Copy link
Contributor

@atrick atrick left a comment

Choose a reason for hiding this comment

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

This looks good for now. Thanks!

One thing we should consider going forward: we may want separate attributes for scoped vs. inherited dependencies. In that world @lifetime would always be an inherited lifetime dependency. A separate attribute would indicate whether a parameter is "borrowed". Let's say @borrow.

Why a separate attribute?

  • Conceptually, we want to separate the concept of a projection vs. a lifetime dependency. Then we don't need to talk about two different kinds of dependencies.

  • @borrow is important for any "value projection" even when the projected value is not ~Escapable. We'll need for ~Copyable projections so that we can find the correct root for a lifetime dependency. It will also be useful for Copyable projections where we don't want copies to be automatically generated for the projected value.

  • Inferring the kind of dependence from the type may get confusing for conditionally ~Escapable types. For example, I think it should be illegal to have a (copied) dependency from a conditionally ~Escapable value to an unconditionally ~Escapable value.

@meg-gupta
Copy link
Contributor Author

@swift-ci smoke test

@meg-gupta
Copy link
Contributor Author

@swift-ci smoke test

@meg-gupta meg-gupta enabled auto-merge September 10, 2024 18:38
@meg-gupta
Copy link
Contributor Author

@swift-ci smoke test

@meg-gupta meg-gupta merged commit 0dde044 into swiftlang:main Sep 11, 2024
3 checks passed
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.

3 participants