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

Type not assignable for string literal in signature #38201

Closed
WangHansen opened this issue Apr 26, 2020 · 6 comments
Closed

Type not assignable for string literal in signature #38201

WangHansen opened this issue Apr 26, 2020 · 6 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@WangHansen
Copy link

WangHansen commented Apr 26, 2020

TypeScript Version: 3.8.3

Search Terms:
string literal
string alias
is not assignable to parameter of type

Expected behavior:
No type check errors

Actual behavior:

No overload matches this call.
  The last overload gave the following error.
    Argument of type 'tAlgorithm' is not assignable to parameter of type '"oct"'.
      Type '"EC"' is not assignable to type '"oct"'.

Related Issues:

Code

interface KeyStore {
    generate(kty: 'EC', crv?: string, parameters?: object, isprivate?: boolean): void;
    generate(kty: 'OKP', crv?: string, parameters?: object, isprivate?: boolean): void;
    generate(kty: 'RSA', bitlength?: number, parameters?: object, isprivate?: boolean): void;
    generate(kty: 'oct', bitlength?: number, parameters?: object): void;
}

type tAlgorithm = "RSA" | "EC" | "OKP" | "oct";

function generateKey(alg: tAlgorithm, crvOrSize: string | number) {
    return ({} as KeyStore).generate(alg, crvOrSize);
}
Output
"use strict";
function generateKey(alg) {
    return {}.generate(alg, "P-256");
}
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

@WangHansen
Copy link
Author

@DanielRosenwasser
Copy link
Member

This clearly shouldn't work given that generateKey("EC", 128) can be substituted with

({} as KeyStore).generate("EC", 128)

and shouldn't match any overload.

@DanielRosenwasser DanielRosenwasser added the Working as Intended The behavior described is the intended behavior; this is not a bug label Apr 27, 2020
@WangHansen
Copy link
Author

WangHansen commented Apr 27, 2020

@DanielRosenwasser Correct, but that is not what the error message is suggesting.
Also, what about the following?

interface KeyStore {
    generate(kty: 'EC', crv?: string, parameters?: object, isprivate?: boolean): void;
    generate(kty: 'OKP', crv?: string, parameters?: object, isprivate?: boolean): void;
    generate(kty: 'RSA', bitlength?: number, parameters?: object, isprivate?: boolean): void;
    generate(kty: 'oct', bitlength?: number, parameters?: object): void;
}

type tAlgorithm = "RSA" | "EC" | "OKP" | "oct";

function generateKey(alg: tAlgorithm) {
  return ({} as KeyStore).generate(alg);
}

This still gives the error.
Playground

Also, could you provide an alternative approach for this function if I want to pass string literals as a parameter of the function?

@DanielRosenwasser
Copy link
Member

Sorry to not also link to the more general problem earlier on (it would've spared you some time): #1805 has some explanation on why the pattern is currently not supported.

Though, since then, I can sort of imagine us doing better given some of the work that went into #30779.

@DanielRosenwasser
Copy link
Member

However, I think that even with the ideas of #30799 incorporated, it wouldn't help you write the original code easily without a type assertion or duplicate overloads.

@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