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

Expose isTypeAssignableTo in TypeChecker? #11728

Closed
MeirionHughes opened this issue Oct 19, 2016 · 8 comments
Closed

Expose isTypeAssignableTo in TypeChecker? #11728

MeirionHughes opened this issue Oct 19, 2016 · 8 comments
Labels
Duplicate An existing issue was already created

Comments

@MeirionHughes
Copy link

MeirionHughes commented Oct 19, 2016

I would like to determine if one Type is assignable to another Type. So far I've only found the type comparison and checking functions in checker.ts, but that entire file is marked internal.

Is there a way to determine if one type is assignable to another using the exposed typescript library? A question to this effect on StackOverflow has not been answered. If not, could such functionality be added, say to TypeChecker?

@MeirionHughes
Copy link
Author

MeirionHughes commented Oct 28, 2016

this seems to be a rather basic change:

types.ts

export interface TypeChecker {
  ...
  isTypeAssignableTo(source: Type, target: Type):boolean;
  ...

checker.ts

const checker: TypeChecker = {
  ...
  isOptionalParameter,
  isTypeAssignableTo
};

basic usage check:

let sourceFoo: ts.SourceFile = foo["source"];
let sourceBar: ts.SourceFile = bar["source"];
let sourceRay: ts.SourceFile = ray["source"];
let declFoo = <ts.ClassDeclaration>sourceFoo.statements.find(x => x.kind == ts.SyntaxKind.ClassDeclaration);
let declBar = <ts.ClassDeclaration>sourceBar.statements.find(x => x.kind == ts.SyntaxKind.ClassDeclaration);
let declRay = <ts.ClassDeclaration>sourceRay.statements.find(x => x.kind == ts.SyntaxKind.ClassDeclaration);

let checker = ref.typeChecker;
let typeFoo = checker.getTypeAtLocation(declFoo);
let typeBar = checker.getTypeAtLocation(declBar);
let typeRay = checker.getTypeAtLocation(declRay);

expect(checker.isTypeAssignableTo(typeFoo, typeFoo)).toBe(true);
expect(checker.isTypeAssignableTo(typeBar, typeBar)).toBe(true);
expect(checker.isTypeAssignableTo(typeFoo, typeBar)).toBe(true);
expect(checker.isTypeAssignableTo(typeFoo, typeRay)).toBe(false);
expect(checker.isTypeAssignableTo(typeBar, typeRay)).toBe(false);

with

  • export class Foo{ field:number = 10; }
  • export class Bar{ field:number = 10; }
  • export class Ray{ field:string }

_alternatively_ expose isTypeRelatedTo instead

@RyanCavanaugh, @mhegazy any chance of a quick look to see if this is acceptable as Community Contribution at least?

@RyanCavanaugh RyanCavanaugh added the Discussion Issues which may not have code impact label Oct 28, 2016
@RyanCavanaugh RyanCavanaugh self-assigned this Oct 28, 2016
@RyanCavanaugh
Copy link
Member

We also had a request from a partner team to expose this and some other functions. This list looks fairly reasonable and shouldn't create any problems -- we'll be following up

isTypeAssignableTo
getAnyType
getUndefinedType
getBooleanType
getNullType
getNumberType
getStringType
createArrayType
getUnionType

@MeirionHughes
Copy link
Author

MeirionHughes commented Nov 17, 2016

@RyanCavanaugh would you allow me to PR a quick change to expose isTypeAssignableTo in TypeChecker, at least, or are you looking to make breaking changes before exposing this?

@weswigham
Copy link
Member

@RyanCavanaugh Also note, This specific issue is encompassed in #9879, which still has #9943 open.

@MeirionHughes
Copy link
Author

MeirionHughes commented Apr 10, 2017

@RyanCavanaugh any progress? This all seems to have stalled. All I really need is for the existing implementation of isTypeAssignableTo to be exposed - I'm happy to make a PR to that effect.

@raveclassic
Copy link

@RyanCavanaugh Same here (#19602), all we need is one function which lands with two lines of changes. Maybe you could add a Community label to this?

@mhegazy
Copy link
Contributor

mhegazy commented Nov 1, 2017

Marking as duplicate of #9879

@mhegazy mhegazy removed the Discussion Issues which may not have code impact label Nov 1, 2017
@mhegazy mhegazy added the Duplicate An existing issue was already created label Nov 1, 2017
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

6 participants