Skip to content

Aliases are lost when conditionals are applied #61581

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

Open
mikearnaldi opened this issue Apr 15, 2025 · 2 comments · May be fixed by #61589
Open

Aliases are lost when conditionals are applied #61581

mikearnaldi opened this issue Apr 15, 2025 · 2 comments · May be fixed by #61589
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@mikearnaldi
Copy link

🔎 Search Terms

aliases lost

🕗 Version & Regression Information

Discussion with @Andarist:

Anyway, I'm sort of leaving breadcrumbs for myself - sorry for oversharing 😉 I'll dig further later

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/C4TwDgpgBAShDOBXANsAPAQQDRQKID4oBeKAbwCgoqoAnCAQwBMB7AO2RCgH1h6BzAFxQARAHkA1sMrU6TNhygA3eskQQhGcgF8oAHzLSqslu049+Q4QDF6AS2RTqtBiYUQaNZjSG5t5cowQAMbI9HRQQWzwwFC28HBIqEIAFIhCiKzirMwA7qwAlMSEiLHwsAgo6PSsIDjVIPj+kazRUABmrMRQmDgEybasYEIJlT14hPrRNAN8hUSEcSOo-YOFAPyxg1CWzJJAA

💻 Code

type Result<A, E> = {
    readonly _tag: "Ok"
    readonly value: A
} | {
    readonly _tag: "Fail"
    readonly error: E
}

declare const isResult: (u: unknown) => u is Result<any, any>

const fn = <A, E>(inp: Result<A, E> | string) => isResult(inp) ? inp : "ok"

🙁 Actual behavior

const fn: <A, E>(inp: Result<A, E> | string) => {
    readonly _tag: "Ok";
    readonly value: A;
} | {
    readonly _tag: "Fail";
    readonly error: E;
} | "ok"

🙂 Expected behavior

const fn: <A, E>(inp: Result<A, E> | string) => Result<A, E> | "ok"

Additional information about the issue

No response

@mikearnaldi
Copy link
Author

Correction, breadcrumbs from @Andarist appears to be unrelated, they instead relate to the following code where it is only the printer at fault, instead in this case aliases are completely lost:

import { Effect, Unify, Option } from "effect"

type Working = Unify.Unify<Effect.Effect<number> | Effect.Effect<string>>
//   ^? - Effect.Effect<number | string, never, never>

type NotWorking = Unify.Unify<Option.Option<number> | Option.Option<string>>
//   ^? - Option.None<number | string> | Option.Some<number | string>

@Andarist
Copy link
Contributor

Fixing this requires making getNarrowedTypeWorker smarter about .origin preservation. It gets lost in this, somewhat unusual, mapType call here:
https://github.dev/microsoft/TypeScript/blob/4dc677b292354f4b9162452b2e00f4d7dd118221/src/compiler/checker.ts#L29346-L29365

Maybe some special path has to be introduced to handle this but maybe it's possible to restructure this somehow so the existing code paths responsible for .origin preservation could kick in.

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases labels Apr 16, 2025
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Apr 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants