instanceof doesn't work if Function interface changes

[rjamesnw]

Extending the Function interface should not cause "instanceof" to fail. Adding new items shouldn't change the fact that it's still a Function instance type. (see http://goo.gl/mCb93P)

interface Function {
    [index: string]: any;
}

class Base { }
class Greeter extends Base {
    greeting: string;
    constructor(message: string) {
        super();
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}

var greeter = new Greeter("world");

var button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function () {
    alert(greeter.greet());
}

document.body.appendChild(button);

var b: Base;
(b instanceof Greeter); <== 'Greeter' is an ERROR

The whole error message is "The right-hand side of an 'instanceof' expression must be of type 'any' or of a type assignable to the 'Function' interface type."

The expected behaviour is that anything that is of type Function would inherit this same change, and thus should not cause errors.

[vladima]

Technically current behavior is by design, we add only properties defined in Function type

3.10.1 Apparent Members
The apparent members of an object type T are the combination of the following:

• The declared and/or inherited members of T.
• The properties of the global interface type 'Object' that aren't hidden by properties with the same name in T.
• If T has one or more call or construct signatures, the properties of the global interface type 'Function' that aren't hidden by properties with the same name in T.

Out of curiosity, what is your use case that you need to add indexer to Function type.

[rjamesnw]

The code was originally from a project prototype that was to implement a type of web OS, and certain hidden properties were placed on the function object's static object (in regards to how meta data was being stored within the name spaces [this included Object, Function, Array, Data, RegExp, etc.]). It's a very special case at the time (things are done differently now), but it's something I did notice when copying over some old code. Just thought I'd mention it to see why, as regardless of use case, I figured it should be expected to work anyway. I think a use case is fine to prioritize things, but not to decide what should be expected to work (IMHO). To be honest, I don't really care - just an FYI. ;)

[danquirk]

The design rationale here is roughly the same as for Object in #835. May warrant a second look given the recent set of people having issues here (ex #1232)