<!--
The main branch is now in convergence, which means major changes, such
as large refactoring or new features, should be avoided. This strategy
is intended to maintain the stability of the Swift 6.4 release leading
up to the May 4th branch. For any work that requires broad changes or
introduces new features, create a feature branch and open a draft pull
request. All updates to the swiftlang/swift repository’s main branch
require approval from the release managers. A pull request targeting
swiftlang/swift will automatically add release managers. You can also
contact them via @release-managers in the forum group.
-->
<!-- Please fill out the following form: -->
- **Explanation**: This reverts commit
5ece334724 which aimed to generalize
Sequence methods for typed throws and resolve its side effects on
overload resolution when a type conforms to both Sequence and
AsyncSequence. There appears to be, at least, one more unanticipated
side-effect, hence this pre-emptive revert in view of the soon-to-be
Swift 6.4 release branching.
<!--
A description of the changes. This can be brief, but it should be clear.
-->
- **Scope**: The said commit is reverted, preserving the recent
~Copyable/consuming alterations to Sequence.reduce(\_:\_:) (#85716).
<!--
An assessment of the impact and importance of the changes. For example,
can
the changes break existing code?
-->
- **Issues**: Under investigation
<!--
References to issues the changes resolve, if any.
-->
- **Risk**: Low
<!--
The (specific) risk to the release for taking the changes.
-->
- **Testing**: None
<!--
The specific testing that has been done or needs to be done to further
validate any impact of the changes.
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
Since generalizing Sequence methods for typed throws, overload
resolution in an async context prefers the corresponding AsyncSequence
methods which cannot be generalized yet. To fix this, all rethrowing
Sequence methods (except withContiguousStorageIfAvailable) are now
duplicated in a new extension (`extension AsyncSequence where Self:
Sequence`).
_See also: #88221_
`func type(of:)` is wholly magical, but it does have a signature in the stdlib (mostly for documentation purposes), and it currently requires its input to be copyable and escapable.
`type(of:)` is actually usable on all entities, so it seems desirable to update its signature to reflect this.
Additionally, this seems like a good time to mark its exported symbol obsolete. I don’t expect anyone would ever link to it (unless there is/was a bug), so in theory we could also silently remove it — but explicitly marking it as legacy ABI seems the least risky option.
We cannot currently express its proper lifetime semantics: its result’s lifetime should depend on the intersection of the lifetime of the left argument and the lifetime of the result of the right argument.
`@lifetime(optional, defaultValue.result)` is what we want, but the `.result` part is not currently expressible. (Tying the dependency on the closure argument itself may be a viable option, but we aren’t confident enough to ship it like that yet.)
Introduce a marker protocol SendableMetatype that is used to indicate
when the metatype of a type will conform to Sendable. Specifically,
`T: SendableMetatype` implies `T.Type: Sendable`. When strict
metatype sendability is enabled, metatypes are only sendable when `T:
SendableMetatype`.
All nominal types implicitly conform to `SendableMetatype`, as do the
various builtin types, function types, etc. The `Sendable` marker
protocol now inherits from `SendableMetatype`, so that `T: Sendable`
implies `T.Type: Sendable`.
Thank you Slava for the excellent idea!
We used to treat 'rethrows' like an attribute, printing it as
'@rethrows', which was incorrect. That's fixed now, so update the
API/ABI checker tests to account for that.
A generic signature's `getInnermostGenericParams` will find the generic
parameters in the innermost scope. That's not quite right for printing
inverses, since we don't want to print an inverse for `T` when emitting
the generic signature of `f` below:
```swift
struct S<T: ~Copyable, E> {
func f() where E == Never {}
}
```
Since `f` has its own generic signature, but doesn't define any generic
parameters, it shouldn't have an inverse emitted. The solution here is
to filter inverses by depth of the generic parameter.
We also want to print _all_ of the inverses in other situations, rather
than just the innermost ones. This aids in debugging and other
tools like the API digester.
resolves rdar://130179698
Andrew Trick
Guillaume Lessard
Clinton Nkwocha
Alejandro Alonso
Ben Cohen
Allan Shortlidge
Alex Hoppen
Guillaume Lessard
Ben Cohen
Anthony Latsis
Karoy Lorentey
Doug Gregor
Hamish Knight
Mike Ash
Kavon Farvardin