Skip to content
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

AsyncIterableX#pipe completely ignores types. #377

Open
jeengbe opened this issue Dec 27, 2024 · 1 comment
Open

AsyncIterableX#pipe completely ignores types. #377

jeengbe opened this issue Dec 27, 2024 · 1 comment

Comments

@jeengbe
Copy link

jeengbe commented Dec 27, 2024

IxJS version: 7.0.0

Code to reproduce: https://codesandbox.io/p/sandbox/typescript-playground-export-forked-9jmsj9?workspaceId=ws_TdkXAMqyc14LovZfzuJaP6

import { AsyncIterableX, from } from "ix/asynciterable";
import { tap } from "ix/asynciterable/operators";
import {
  MonoTypeOperatorAsyncFunction,
  MonoTypeOperatorFunction,
} from "ix/interfaces";
import { IterableX } from "ix/iterable";

declare const sync: IterableX<number>;
declare const async: AsyncIterableX<number>;
declare const syncOp: MonoTypeOperatorFunction<string>;
declare const asyncOp: MonoTypeOperatorAsyncFunction<string>;

sync.pipe(syncOp);
//        ~~~~~~ Errors, as it should
async.pipe(asyncOp);
//         ^^^^^^^ No error!

// Demo, will crash at runtime
from([1, 2, 3]).pipe(tap((val: string) => val.length));

Expected behavior: The function signature should prevent piping an AsyncIterable<number> into an operator that expects string. The attached code demonstrates how this could end up bad.

Actual behavior: According to TS, the expression is a-ok for async iterables. Note that it works as intended for sync iterables.

Additional information:

@trxcllnt
Copy link
Member

Thanks for the report, this definitely seems odd. What version of typescript are you using?

Minor annoyance in that the sync.pipe() call is decaying to the WritableStream case:

No overload matches this call.
  The last overload gave the following error.
    Argument of type 'MonoTypeOperatorFunction<string>' is not assignable to parameter of type 'WritableStream'.ts(2769)

But at least TS is inferring the OperatorFunction<T, R> correctly:
image

In the AsyncIterable case, it's decaying to OperatorAsyncFunction<any, any>, and I'm not sure why:
image

We've been through a few TS upgrades since these signatures were written, there may be a better way to write this now. I'll investigate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants