Closed gsl-anthonymerle closed 4 months ago
Yes, seeing this with Swift 6.0 on Linux as well.
+1
Possible solutions that I'd like to explore:
AsyncSubject.Failure
type on their end.
Even worse, when targeting for iOS 18 this may introduce silent bugs because AsyncSubject.Failure
will not be the client's expected associatedtype anymoreFuck Apple!
Here is my temporary solution, which can be viewed in my branch.
#if swift(>=5.9)
public protocol AsyncSubjectable: AnyObject, AsyncSequence, Sendable where AsyncIterator: AsyncSubjectIterator {
func send(_ element: Element)
}
public protocol AsyncSubjectTerminator {
associatedtype Failure: Error
func send(_ termination: Termination<Failure>)
}
public typealias AsyncSubject = AsyncSubjectable & AsyncSubjectTerminator
#elseif swift(>=5.7)
public protocol AsyncSubject<Element, Failure>: AnyObject, AsyncSequence, Sendable where AsyncIterator: AsyncSubjectIterator {
associatedtype Failure: Error
func send(_ element: Element)
func send(_ termination: Termination<Failure>)
}
#else
...
#endif
Thanks @0xfeedface1993! :o This works like a charm! I allowed myself to create a pull request with this change, as I was able to test it and confirmed it work and compiles on both Xcode 16 and Xcode 15 🙏
fixed here: https://github.com/sideeffect-io/AsyncExtensions/pull/42
Thanks a lot.
Describe the bug Hi, so I updated Xcode to v16 and tried to build my app for iOS 18 but the AsyncExtensions module got some compilation errors regarding AsyncSubject's Failure associated type.
To Reproduce Steps to reproduce the behavior:
Expected behavior The application should build without any error
Screenshots
Environment:
Additional context After digging a bit into the code, I think that's because
AsyncSubject
end up defining twoFailure
associated type from iOS 18:AsyncSubject
has its ownFailure
associated typeAsyncSubject
needs to conform to Swift Concurrency'sAsyncSequence
AsyncSequence
defines its ownFailure
associated type starting iOS 18