Specialized signature merging

Topics: Language Specification
Feb 4, 2014 at 12:11 AM
Edited Feb 4, 2014 at 3:30 AM
Possibly related to https://typescript.codeplex.com/discussions/474481.

Given the following:
interface A {
    get(key:'string'):string;
    get(key:'number'):number;
    get(key:string):any;
}

interface B extends A {
    get(key:'boolean'):boolean;
    get(key:string):any;
}
In this case, code intel on B will provide only the one subtype in interface B, instead of merging with the subtypes specified in interface A. This is incredibly unhelpful. In fact, it looks like not even lib.d.ts expects things to work this way as many of the interfaces there (on develop branch) are doing things like interface Window extends GlobalEventHandlers, but then the signatures from GlobalEventHandlers are not ever actually applied.

I’d propose that either you can extend an interface and not provide the base signature (in other words, exclude get(key:string):any; from interface B above) in which case they merge in, or just merge them regardless and authors can define explicit overrides if they want to change the specifics of one of the inherited specialized signatures.

edit: I think it’s also important to consider the case where you want to implement an interface with a class, and want to have the type signatures from the class and only write the implementation, without needing to redefine all the overloads.
Coordinator
Feb 5, 2014 at 3:18 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.