Deprecating/Removing `Observable` for Swift 5.7/6.0

[Jacob Christie]

Short description of the issue:

With the introduction of generics UI enhancements in Swift 5.7, there seems to be little to no utility in having the Observable type eraser.

Expected outcome:

Instead, a user can write some ObservableType<MyElement> or ObservableType<MyElement>/ any ObservableType<MyElement> if they need a dynamic return type (after updating ObservableType to have a primary associatedtype). It feels natural that ObservableType could be renamed to Observable in Swift 5.7. For most consumer code, this should be source compatible. I would expect that those implementing many custom observables, etc. will have minor source breakage. In Swift 6, user's will currently forced to prepend any/some to their use of the bare protocol (though it's currently being discussed if some will be the new default for bare protocols). If we introduce this with Swift 5.7, any source break it can be just a part of the users' migration to Swift 6.

Self contained code example that reproduces the issue:

#if compiler(5.7)
  typealias ObservableType = Observable
  protocol Observable<Element> {
    associatedtype Element
   // ...
  }
#elseif
  protocol ObservableType { ... }
  class Observable<Element> { ... }
#endif

RxSwift/RxCocoa/RxBlocking/RxTest version/commit

version or commit here

Platform/Environment

• iOS
• macOS
• tvOS
• watchOS
• playgrounds

Xcode version:

  Xcode 14

Level of RxSwift knowledge:
(this is so we can understand your level of knowledge
and formulate the response in an appropriate manner)

• just starting
• I have a small code base
• I have a significant code base

[Shai Mishali]

Hey, thanks for the suggestion :)

I'm not sure I entirely see the immediate value of making such a migration, but I'm generally open to improving some things related to the new Swift 5.7 generics additions. I don't think we'll want to do it before the next major version, though, as it will not be ABI Compatible (even if it'd be source compatible). So we usually make such changes only if there's a very big value to it, which I'm not sure if exists here.

Generally making it a compiler directly like you're suggesting here gives both Observable and ObservableType entirely different meanings on different compilers which will be extremely confusing, so I'm unsure this is the right path to go. Can you explain more what value will this create?

[Joseph Duffy]

I was just looking for this myself, the primary benefits from my perspective are:

• I believe this would remove the need for asObservable() because Swift would do all of the boxing required without any additional casts or calls required
• ObservableType can be deprecated, and a smaller API is always nice

I might be wrong about this, but that's my understanding 😄

[Shai Mishali]

Once we'll start working on an RxSwift 7 branch, I'll be happy to explore this option :)