-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Observable<never> is not assignable to Subscribable<T> #3891
Comments
This looks like a bit of a problem, as the signature for |
Removing the positional parameters solves the problem too |
@felixfbecker Ah, I see what you mean. It's already lying. Also, regarding the WHATWG proposal, I've not (re)read the entire thread, but this comment suggests that its implementation of The signature of |
* fix(subscribable): make subscribe() signature match Observable Fixes #3891 * test: cast string | number to string before concatenating T of this Observable is string | number, so TypeScript does not allow using +. The desired behaviour for this function is to concatenate the string values, so cast to strings. On master, these were incorrectly inferred as never, which is why this error was not surfaced. * test: correct type for selector function The hot() function will create an Observable that emits strings from marble diagrams (even if the strings contain numbers). So the type of x should be string, not number.
Bug Report
Current Behavior
Kinda related to #3890, when trying implement interop by accepting
Subscribable
as input, you cannot passObservable<never>
into anySubscribable<T>
.This is because
Subscribable
's signature forsubscribe
doesn't match that ofObservable
:vs
So you get this error:
Reproduction
Expected behavior
An Observable that
never
emits should be assignable to anyObservable
of any type, since the type doesn't matter if it never emits. This is the semantic ofnever
.Environment
Possible Solution
Change the signature of
Subscribable.subscribe
to use an overload, which in my eyes more accurately represents the actual interface.With the current signature, this is possible, which it shouldn't:
What would get logged?
The text was updated successfully, but these errors were encountered: