Could you not use a type-erasing wrapper (some kind of AnySubscription) to overcome the existential problem?
There might be a performance cost (maybe. Not sure if existentials are that fast anyway), but at least the API would be sound.
Yea, that was a consideration in one of the refactoring efforts I did, however it did end up making some changes to the Combine core protocols in doing so. However it was decided that would be too risky of a change in this stage of development.
1 Like
@ben-cohen What is the status of this proposal? Has it been discussed by the core team?
@Philippe_Hausler Okay, so would it be correct to say it's more an issue of it not being practical to support in version 1.0 of Combine, rather than an intrinsic issue with the protocol's design?
Proposal Accepted
The proposal has been accepted. Thanks for everyone for participating.
3 Likes
Yup! Sorry for the delay, this was discussed and accepted recently. I'd suggest continuing any discussion around Combine in particular on a new thread in the discussion topic.
2 Likes
Can someone explain to me the need for
@available(macOS 10.15, iOS 13, tvOS 13, watchOS 6, *)
I do not understand the need for iOS 13+ or any other plateform requirement for that matter
Hi Denis,
Now that Swift is part of the OS on those platforms, most new additions to the standard library will require availability of the OS in which they first shipped. New protocols or types needs to exist in the OS for them to be shared between different binaries (e.g. between the app and the frameworks that app uses). They simply won’t exist on older OSs.
1 Like