Issue 1:
The current construct signature for Promise in es6.d.ts is this:

new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

I would like all of these to definitely compile:

new Promise(resolve => resolve()); // (1)
new Promise<void>(resolve => resolve(null)); // (2)
new Promise<number>(resolve => resolve(5)); // (3)

... these to maybe compile:

new Promise<void>(resolve => resolve()); // (4)
new Promise(resolve => resolve(5)); // (5), and also inferred as Promise<number>

... and this to not compile:

new Promise<number>(resolve => resolve()); // (6)

Currently all of these compile, including (6), although (5) is inferred as Promise<{}>

Changing value to required makes (6) not compile, but also breaks (1) and (4). By then adding one more overload:

new (executor: (resolve: () => void, reject: (reason?: any) => void) => void): Promise<void>;
new <T>(executor: (resolve: (value: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

(1) to (3) will continue compiling, and (4) to (6) will stop compiling. Since (5) was not being inferred correctly anyway, I think it's okay that it won't compile. Losing (4) is perhaps the bigger problem, since it will break existing code that uses it.

PromiseConstructor.resolve already does this - it has one overload with no type parameter and no parameter that returns Promise<void>, and one with a type parameter and a required parameter that returns Promise<T>. I seem to remember Promise's construct signature also did used to do the same at one point (maybe back when it was in lib.d.ts?) which is why I was surprised to discover that it doesn't now.

Issue 2:
This proposal is based on a working implementation at:

https://github.com/yortus/TypeScript/tree/preprocessor-directives

Problem Scenario

Whilst the TypeScript compiler has some options to control what to emit for a particular source file, it currently has limited support for controlling what is scanned into the compiler from a particular source file. A source file is either included in its entirety, or not at all.

This makes some scenarios difficult. For instance, there are two default lib files, lib.d.ts, and lib.es6.d.ts. A program may be compiled against one, or the other, or neither. If only some ES6 typings are desired, then either they must all be taken (using lib.es6.d.ts), or a custom set of core typings must be maintained with the project.

Even if the core lib files were further subdivided into smaller modular files that could be selectively included in a build, problems would remain. For instance, consider an ES6 built-in, WeakMap, which has members that use the ES6 Symbol spec and the ES6 Iterable spec. How many files must the WeakMap definition be broken into to keep the lib files feature-modular?

Related scenarios have been discussed in other issues:

(#4671) Conditional compilation

(#3670) Preprocessor directives proposal

(#3538) Proposal: Conditional Compilation

(#449) Support conditional compilation

This proposal focuses on the lib.d.ts modularity problem, since that was the core requirement for the related proposal (#4692) that motivated the working implementation.

Workarounds

With regards to compiling core typings for only some ES6 features, some workarounds are:

compile with --target ES5 and selectively add ES6 typings in separately maintained files (eg from DefinitelyTyped).

compile with --target ES6 and be careful to avoid referencing unsupported ES6 features (the compiler won't issue any errors).

compile with --noLib and manually maintain custom core typings in your own project.

For other scenarios, such as supporting DEBUG builds or IOS builds etc, a common practice is to use a single codebase with conditional execution to differentiate behaviour in different environments. This generally works well, except if conditional require(...)s are needed, as these can be a problem for some module systems that statically analyse module dependencies.

Proposed Solution

This proposal adds a new kind of syntax for preprocessor directives.

Preprocessor Directive Syntax

A preprocesor directive:

begins with a '#' followed by the directive identifier, eg #if, #endif

must be the first non-whitespace element on its line

must not be followed on the same line by anything other than whitespace and/or a single-line comment

Valid:

#if DEBUG
#endif // end of debug section

Invalid:

} #if DEBUG
#if X foo(); #endif

Directives with Arguments

A preprocessor directive may take an argument. If so, the argument appears after the directive identifier on the same line. The directive identifier and its argument must be separated by at least one whitespace character.

Under this proposal, only #if takes an argument, which must be an identifier. An extended proposal may expand argument syntax to include preprocessor symbol expressions.

Contextual Interpretation

If a syntactically valid preprocessor directive appears inside a multiline comment or a multiline string, it is not considered a preprocessor directive. It remains a normal part of the enclosing comment or string.

/*
The next line is NOT a preprocessor directive
#if XYZ
*/

Preprocessor Symbols

A preprocessor symbol is an identifier used with some directives (only #if under this proposal). Preprocessor symbols have no values, they are simply defined or undefined. Under this proposal, the only way to define a preprocessor symbol is using the define compiler option (see below).

Preprocessor symbols are in a completely separate space to all other identifiers in source code; they may have the same names as source code identifiers, but they never clash with them.

#if DEBUG
#if SomeFeature
#if __condition
#if TARGET_HAS_ITERABLES

#if and #endif

The #if and #endif preprocessor directives signal the start and end of a block of conditionally compiled source code. #if must be given a preprocessor symbol as an argument. #endif takes no argument. Each #if in a file must have a matching #endif on a subsequent line in that file.

When the TypeScript compiler encounters an #if directive, it evaluates its preprocessor symbol against a list of defined symbols. If the symbol is defined, then the TypeScript scanner continues scanning the source file normally, as if the directive was not present. If the symbol is not defined, then the compiler skips all the source code down to the matching #endif without compiling it.

#if...#endif blocks may be nested. Inner blocks will be unconditionally skipped if their outer block is being skipped.

#if HAS_FOO
foo();
#endif

#if HAS_FOO
foo();
#if HAS_BAR
foo() + bar();
#endif
#endif

The define Compiler Option

Preprocessor symbols may be defined at compile time using the define compiler option, which takes a comma-separated list of identifiers.

tsc --define FOO,bar

{
"target": "es6",
"define": "DEBUG,__foo,ABC"
}

Possible Extensions

This proposal is limited to a small set of features that are useful on their own, but may be expanded.

In particular, #if and #endif alone are sufficient to address the lib.d.ts problem described above, as evidenced in the working implementation of #4692. The ability to nest #if...#endif blocks effectively allows logical ANDing of preprocesor symbols.

Possible extensions include:

#define and #undef directives to add/remove preprocessor symbols from within source code. However the question of symbol scope then arises.

Unary and binary expressions involving preprocessor symbols, such as ! (logical NOT), && logical AND, and || logical OR.

Backward Compatibility, Design Impact, Performance, etc

There is no impact on existing TypeScript projects. The preprocessor directives only modify the compiler's behaviour if they are explicitly used.

Preprocessor directives introduce new language syntax, but do not affect any existing language features.

There is negligable impact on compiler performance.

The hash symbol is only used in shebang trivia at present. There is no syntax clash. But could it be used for something in a future ES standard?

Remaining Work and Questions

The working implementation implements preprocessor directives in the TypeScript scanner, since they are really a filter on incoming tokens. This works fairly well for this limited proposal, but questions arise if extensions were added:

if #define/#undef were added, how should preprocessor symbols be scoped? Global? Per file? The scanner has very limited control over scoping. Hence currently preprocessor symbols are all globally scoped and provided using a compiler option (or internally generated by the compiler).

Supporting expressions as preprocessor arguments would add complexity to the scanner, as it would need to parse a mini grammar for the expression, which would be atypical at the lexer stage. But certainly doable.