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

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

Cancellation Signals

• Introduction
• CancellationTokenSource
• CancellationToken
• Examples
• Reference Implementation

Introduction

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

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

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:

rbuckton

/** 
  * Basic shape for a type.
  */
interface Type {
    /** 
      * Describes the specific shape of the type.
      * @remarks 
      * One of:
      *     "any"           -> IntrinsicType
      *     "number"        -> IntrinsicType