Global type references

[ahejlsberg]

When a type declaration in an inner module has the same name as a type declaration in an outer module, the outer declaration becomes inaccessible. Programmers can typically work around this, for example by deriving a type with an alternate name in the outer module or, with our latest changes, by declaring a type alias. However, such manual work-arounds are not a good option for code generation tools such as the .d.ts generation facility provided by the compiler. We really need a fool proof way to ensure a lookup starts at the global scope. Consider:

function makeError(): Error {
    return new Error("We've got a problem");
}

module M {
    export class Error {
    }
    export var x = makeError();  // No way to name global Error type here
}

It is currently impossible to create a .d.ts file for the code above because there is no way to emit a type annotation for x that references the global interface Error.

Node.js uses the name global for the global scope. We could consider supporting something similar in type names. Specifically, if a qualified type name starts with the identifier global and if a lookup of global as a module name doesn't bind to anything (meaning the user didn't define a global module), then we consider it a globally qualified name. For the example above we could then generate the following .d.ts file:

declare module M {
    class Error {
    }
    var x: global.Error;
}

If course, if the user defines their own global module we now have a problem again--but I think it is fine to just say you shouldn't do that. We could even consider making it an error, or allowing it only under a compiler switch.

[mhegazy]

how about a global modifier instead of reserving the name something like ``global::`:

declare module M {
    export class Error {
    }
    var x: global::Error;
}
var e: global::M.Error;

[DanielRosenwasser]

global:: is interesting. C++ has ::x to retrieve an x in the global namespace, so it sort of reminds me of that.

[RyanCavanaugh]

We just as much need to solve the problem for external modules, so we'd need another special identifier that meant "the containing external module". global makes sense for internal modules but I think we'll have a hard time finding a non-conflicting equivalent for external modules. Just using a different syntax seems like a cleaner solution at that point.

[sccolbert]

👍 for a way to explicitly resolve global scope

[basarat]

It is possible with a bit of _ab_use of declare var and typeof:

function makeError(): Error {
    return new Error("We've got a problem");
}

declare var GlobalError:Error;

module M {
    export class Error {
    }
    export var x:typeof GlobalError = makeError();  // captured global type Error
}

Related stackoverflow question: http://stackoverflow.com/a/27433864/390330

I think the fact that these kinds of ugly workarounds are necessary illustrates the need for a supported method of accessing the global scope.

I could get behind either global::foo or ::foo.

[basarat]

I could get behind either global::foo or ::foo

👍 for ::foo

Reason: I don't like the confusion global will create with respect to something actually called global e.g. http://nodejs.org/api/globals.html#globals_global

[mhegazy]

The main objection to :: is that it looks bad in a type position:
var x: ::Error;

[cseufert]

Could we just use a leading . so .File or .Error, in the vein of PHP with \BuiltInClass.

Alternatively, when in a browser context, use window.File, or window.Error, since whats were they are declared, rather than adding a new syntax.