Add Support for design-time decorators

Now that decorators are supported in TypeScript (#2249), consider adding support for ambient/design-time-only decorators:

Ambient decorators can be an extensible way to declare properties on or associate special behavior to declarations; design time tools can leverage these associations to produce errors or produce documentation. For example:

Use cases:

• Deprecated/Obsolete, to support warning on use of specific API’s:

interface JQuery {  
    /**  
     * A selector representing selector passed to jQuery(), if any, when creating the original set.  
     * version deprecated: 1.7, removed: 1.9  
     */  
    @@deprecated("Property is only maintained to the extent needed for supporting .live() in the jQuery Migrate plugin. It may be removed without notice in a future version.", false)  
    selector: string;  
}

• Suppress linter warning:

@@suppressWarning("disallow-leading-underscore")   
function __init() {  
}

Proposal

Design-time (Ambient) decorators are:

• ambient functions
• have a special name starting with “@”
• are not emitted in output JS code, but persisted in .d.ts outputs.

Application

• Applying a design-time can only accept constant values. Variables would not be observable by the compiler at compile time. Here is the set of possible values:
  • string literal,
  • number literal,
  • regexp literal,
  • true keyword,
  • false keyword,
  • null keyword,
  • undefined symbol,
  • const enum members,
  • array literals of one of the previous kinds,
  • object literal with only properties with values of one of the previous kinds

[kitsonk]

@mhegazy I might not be the best person to expound upon the proposal, as I have only lived in JavaScript land for an extended period of time (and Delphi a long time ago) and some of the Reflection and Type handling that are part of C# and other languages I am not familiar with.

I guess what I am suggesting is that at design time, in these decorators, some of the internal TypeScript constructs would be available. For example, the ability to construct and return a new type, similar to the C# TypeBuilder.CreateType

But I guess from my perspective, if I had some programmatic design time access to types via these design-time decorators, I could implement language features (mixins/traits) without needing syntatical support in typescript. From a “vision” objective, I would see something like this:

function mixin(target: any, ...mixins: any[]): type {
    const typeTarget = typeof target;
    mixins.forEach((mixin) => {
        const typeMixin = typeof mixin;
        for (let t in typeMixin) {
            typeTarget[t] = typeMixin[t];
        }
    });
    return typeTarget;
}

class A {
    foo() { return false; }
}

class B {
    bar() { return 'bar'; }
}

@@mixin(A, B)
class C {
    baz() { return 1; }
}

const c = new C();
console.log(c.foo(), c.bar(), c.baz());

Of course, I could put a lot of different logic in there, but essentially I could perform design-time operations on the types. I don’t know the inner workings of the compiler, but I suspect there would be good set of semantics for safely programmatically operating on types.

[cspotcode]

Another use case is enforcing an interface for the static side of a class.

declare function @StaticImplements<T>(t: T): T;
interface Foo { prop: string; }
@@StaticImplements<Foo> class MyClass { static prop = 'hello world'; }