rbuckton

Function Decorator

// definition
function functionDecorator(target /*: Function */) /*: Function | void */ { 
  // ...
}

// application
@functionDecorator 
function targetFunction() {}

rbuckton

Proposed Format

/* 1.*/  {
/* 2.*/    "version": 3,
/* 3.*/    "file": "out.js",
/* 4.*/    "sourceRoot": "",
/* 5.*/    "sources": ["foo.js", "bar.ts"],
/* 6.*/    "sourcesContent": [null, null],
/* 7.*/ "names": ["src", "maps", "are", "fun"],

rbuckton

module Reflect {
    "use strict";

    const weakMetadata = new WeakMap<any, Map<any, any>>();
    const weakPropertyMetadata = new WeakMap<any, Map<PropertyKey, Map<any, any>>>();
    const weakParameterMetadata = new WeakMap<Function, Map<number, Map<any, any>>>();
    
    /**
      * Applies a set of decorators to a target object.
      * @param target The target object.

rbuckton

interface ClassDecoratorDescriptor<TFunc extends Function> {
  target: TFunc;
  
  // TypeScript specific
  type?: Function;
  paramTypes?: Function[];
  returnType?: Function;
}

rbuckton

Summary

One issue introduced by decorators is that any attempt to use them on a function declaration would either necessitate a TDZ for the declaration, or would need to be an error. This limits the usefullness of decorators.

Another issue is that many use cases for annotations need a coherent runtime API that allows for imperative reflection for annotations of an object, its members, or the parameters of a function.

This document describes two parts to a solution for unifying decorators and annotations:

1. Marking decorators as "early" with the @decorator decorator.
2. Extending the Reflect API with a comprehensive set of functions for reflecting and managing metadata.

rbuckton

/**
  * A source for cancellation
  */
export declare class CancellationTokenSource {
    /**
      * @param links Other `CancellationToken` instances that will cancel this source if the tokens are canceled.
      */
    constructor(links?: CancellationToken[]);
    /**
     * Gets the `CancellationToken` for this source.

rbuckton

declare namespace Reflect {
    /**
     * Gets a mirror for the target.
     *
     * @param target The target of the mirror.
     * @param usage The intended usage for the mirror, either a read-only introspection mirror or a writable mutation mirror. Default "mutation".
     * @returns A mirror for the provided target.
     */
    function mirror(target: any, usage?: "introspection" | "mutation"): ObjectMirror | FunctionMirror | ClassMirror | undefined | null;
}

rbuckton

// operators proposal

// partial application (? and ...)
f(?, 1)             // (_a = f, _b = 1, (_c) => _a(_c, _b))
f(?, 1, ?)          // (_a = f, _b = 1, (_c, _d) => _a(_c, _b, _d))
f(?1, ?0)           // (_a = f, (_b, _c) => _a(_c, _b))
f(...)              // (_a = f, (..._b) => _a(..._b))
f(?, 1, ...)        // (_a = f, _b = 1, (_c, ..._d) => _a(_c, _b, ..._d))
o.f(?, 1)           // (_a = o.f, _b = 1, (_c) => _a(_c, _b))                     

rbuckton

NOTE I have yet to update this proposal, but I find @domenic's version here to be a much improved implementation:

Promise.prototype.finally = function (callback) {
    return this.then(
        value => this.constructor.resolve(callback()).then(() => value),
        reason => this.constructor.resolve(callback()).then(() => throw reason)
    );
};

rbuckton

Proposal

Add a generic "rest" type parameter, for use with Tuples. The goal of this feature is to provide better type support for certain operations that either cannot be reliably typed today, or could be more easily written.

Syntax

A generic "rest" type parameter is written in the form ...T. When generic types are inferred, this would be expanded into T0, T1, ... Tn. This type parameter can only be used inside of a tuple type, using the form [...T], which would be expanded into [T0, T1, ... Tn].

Scenarios

bind

Currently, if you wanted to write something like bind with generics, you have two options: