Hello, Swift community.
SE-0446 added basic language support in Swift for non-escapable types, whose values are restricted in scope. However, it intentionally left out the ability for functions and properties to return values of these types, pending a future proposal to add lifetime dependencies. The design and implementation of that proposal is still in progress. In the meantime, SE-0456 added multiple properties to the standard library which return Span, a non-escapable type. These properties have been defined using a feature, @lifetime, that is not yet officially in the language.
There are good reasons why the Language Steering Group is wary of formalizing @lifetime as it stands today as the right way to write lifetime dependencies, which is why it has not been proposed as an official feature. Once an official feature is developed and accepted, we won't really want to keep any unofficial aspects of @lifetime around forever as an alternative.[1] However, we're conscious that the development of that feature may take a few releases, and we want developers to be able to take advantage of non-escapable types like Span in their own code and APIs in the meantime. We also want to know what problems developers run into with these types, and we want to understand what features they need from a lifetime-dependency design. That feedback is only going to come from meaningful adoption, and the LSG is concerned that that adoption will be highly limited without some level of support for lifetime dependencies.
The Language Steering Group is therefore considering introducing @lifetime as a supported experimental feature in Swift 6.2. Calling something a supported experimental feature means making the following commitments:
- There will be a design document for the supported experimental feature published in some to-be-determined place. This may be somewhat rougher and less thorough than a normal evolution proposal document, but it will lay out what developers can do with the feature. The feature will become usable in official Swift releases using an appropriate
-enable-experimental-featureflag. - A supported experimental feature will not be deprecated until there is some way to express all of its documented functionality using official features.[2] The release that deprecates it will include automated tooling for migrating to those features, and that tooling will remain usable for at least as long as the experimental feature itself.
- If the supported experimental feature is deprecated in the future, it will remain usable in official Swift releases for at least three releases after its deprecation. For example, suppose that a supported experimental feature is introduced in Swift 6.2, and an official feature replacing it is added in Swift 6.4. The LSG will announce that the experimental feature is considered deprecated in the 6.4 release, but it will still be usable in (at minimum) the 6.2, 6.3, 6.4, 6.5, and 6.6 releases. This gives adopters of the experimental feature an extended window in which to adopt the official feature.
- Official features will not have tighter deployment restrictions than the experimental features they replace except as absolutely necessary. In general, features that require runtime support are not good candidates for being supported experimental features in the first place, since the runtime support may need to evolve as the feature does.
We believe that this is a good framework for allowing programmers to take early advantage of features that are still under development. In particular, we think this can be very valuable when an official feature is "unlocked" by another feature that may be significantly more complex. That is certainly the case with non-escapable types (like Span) and lifetime dependencies.
Programmers who are uncertain if they will be able to migrate off a supported experimental feature within its supported window should generally just wait for the official feature to be released.
We will create a separate thread in the coming weeks to discuss @lifetime specifically. Please keep any feedback in this thread focused on the general concept of supported experimental features.
John McCall
Language Steering Group
Possibly including the entire attribute, if the official design goes in a very different direction. ↩︎
The LSG may decide to intentionally restrict this functionality, e.g. if it thinks something expressible with the experimental feature is actually a bad idea and should not be supported. But that's the standard for omitting functionality, not just that the official feature covers the most important things that used to be expressible. ↩︎