Skip to content

Conditionally typed parameter and unions not enforced #39786

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

Closed
jeffijoe opened this issue Jul 28, 2020 · 4 comments
Closed

Conditionally typed parameter and unions not enforced #39786

jeffijoe opened this issue Jul 28, 2020 · 4 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@jeffijoe
Copy link

TypeScript Version: 3.9.2

Search Terms: typescript pass callback undefined conditional type

Expected behavior: passing a callback that specifies T as the parameter type to a target that specifies T | undefined after evaluating the conditional type should emit an error.

Actual behavior: passing a callback that specifies T as the parameter type to a target that specifies T | undefined after evaluating the conditional type does not emit an error, resulting in potentially attempting to access properties of undefined. By wrapping it in (v) => callback(v) however, the behavior is correct.

Related Issues: Some that might have the opposite problem? Not sure though. #26013

Code

interface Params<T, B extends boolean> {
    shouldUseArray: B
    callback(value: B extends true ? T[] : T | undefined): void
}

declare function fn<T, B extends boolean>(value: T, params: Params<T, B>): void

declare function myCallback(num: number): void

const input: number = 123

fn(input, {
    shouldUseArray: false,
    // good, the undefined check is enforced
    callback: v => myCallback(v)
                          //  ^ possible undefined, so this works
})

fn(input, {
    shouldUseArray: false,
    // bad, the undefined check is not enforced
    callback: myCallback
})
Output
"use strict";
const input = 123;
fn(input, {
    shouldUseArray: false,
    // good, the undefined check is enforced
    callback: v => myCallback(v)
});
fn(input, {
    shouldUseArray: false,
    // bad, the undefined check is not enforced
    callback: myCallback
});
Compiler Options
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

Playground Link: Provided

@RyanCavanaugh
Copy link
Member

Functions declared with method syntax are checked bivariantly. You should write it as

    callback: (value: B extends true ? T[] : (T | undefined)) => void

if you want contravariant parameter checking, which you do.

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jul 29, 2020
@jeffijoe
Copy link
Author

jeffijoe commented Jul 29, 2020

Interesting, I didn't know that! I always thought the 2 were equivalent.

What's the rationale behind that? Is it documented somewhere?

I thought it would be a bug because I got some runtime errors because of it.

@RyanCavanaugh
Copy link
Member

See comments in #18654

We need to add this to the reference pages in the new TS Handbook. Unfortunately this is the kind of thing where no one goes digging through the docs to discover it until after they've already noticed, at which point it's already sort of too late.

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants