My two main grudges against Typescript:
1) Union types can't be passed as arguments if there is a variant for every element of the union
2) No tuple polymorphism, i.e. [T, U] isn't assignable to [T]. This is not a mistake because the length of the arrays differs and therefore they may be interpreted in a different way, but IMO there should be a tuple type which is actually an array but length is unavailable and it supports polymorphism. This sounds stupid, but since function parameter lists work well with tuples it would actually enable a lot of functional tricks that are currently inaccessible.

1) Would you like to clarify? I don't quite get what you're saying.
2) Tuples aren't part of JavaScript. Tuples in TypeScript is really just a fixed length array enforced by types. TypeScript really only adds type safety and doesn't really aim to extend JavaScript more than necessary, and assigning an array of longer length and removing excess values would be adding new functionality.

@ScriptCoded 2) All you have to do is ignore the length property (prevent access to it through the existing type system) and short tuples become regular subtypes of their extensions. It definitely doesn't require modifications to the emitted javascript.

@ScriptCoded 1)
@highlight

declare const x: number|string
declare function f(n: number): number
declare function f(s: string): string

const y = f(x)
// expected: y is string|number
// reality: type error

@lbfalvy

2) Sure, that's true for a constant assignment. But take a variable, how would you do that?

const a = b.slice(0, 1)?
const a = [b[0]]?

Still syntax that doesn't have a clear javascript equivalent. I think the TypeScript developers mention somewhere that they aim for TypeScript to be as close to JS as possible.

1) I agree, that should work... There should always be an underlying implementation like this which means that your code shouldn't throw:

function f(x: number|string): number|string

@ScriptCoded 2) Naturally, such a tuple would have to disallow array methods that depend on length, but you wouldn't .slice() a tuple in any other language either.

@ScriptCoded 1) I don't think we should be adding overloads that don't contain new information to please the type system.

@lbfalvy

2) That's the thing, that'd be the case if TypeScript was it's own language or if JavaScript were to have tuples, but neither is true. TypeScript is a superset of JavaScript and there must be an equivalent JavaScript version of the snippet.

1) Well, that's how TypeScript handles overloading (https://typescriptlang.org/docs/...), and it makes sense. Similar to conversion 2 JavaScript doesn't have overloading and there has to be an equivalent there. That equivalent is a single function that in a typed world would have multiple signatures and has logic to decide what to do.

In your example you used a type definition file which really is just a description of how a plain JavaScript file looks and behaves. It has a lot less constraints than a typical TypeScript file, probably because it's really meant to be generated by the TypeScript compiler. In a normal TypeScript file the compiler/checker would complain.