GeezerVison

cc Anders Hejlsberg (@ahejlsberg) so you can get an idea of what I've been going on about it not being that bad of a change if we don't want it to be.

Oh, and TypeScript Bot (@typescript-bot) pack this because why not

And TypeScript Bot (@typescript-bot) run dt while I'm at it - considering this only affects what were error cases before....

Heya Wesley Wigham (@weswigham), I've started to run the parallelized Definitely Typed test suite on this PR at 6c9e85c. You can monitor the build here. It should now contribute to this PR's status checks.

Heya Wesley Wigham (@weswigham), I've started to run the tarball bundle task on this PR at 6c9e85c. You can monitor the build here. It should now contribute to this PR's status checks.

Hey Wesley Wigham (@weswigham), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/41288/artifacts?artifactName=tgz&fileId=282DB72299055B907AB20A7ED54753A4D316F6BCAA024E532660281DC96C42BF02&fileName=/typescript-3.7.0-insiders.20190821.tgz"
    }
}

and then running npm install.

_{https://twitter.com/SeaRyanC/status/1128332816163278853}

DT looks like master's DT, as expected, this has no change in any extant non-erroring code~

How does this deal with conditional types? #26980

Well, I mean, I already have a test in the PR that uses one inside of a tuple in an alias.... So...maybe? Haven't tried yet - so long as we're not immediately unwrapping the substitute before we manufacture the type (which we may do sometimes for conditionals to facilitate simplification), it might work.

Recursive conditional types would be great and make it possible to model, e.g. Array.prototype.flat with infinite depth (well, “infinite” up to the instantiation depth limit anyway):

// note: might not be 100% correct
type Flattened<T> = T extends (infer U)[][] ? Flattened<U[]> : T;

Bruce Pascoe (@fatcerberus) If you're trying to model actually performing it at the type level, that'd be how you would do it (assuming this even handles that). But it does beg the question, if combined with #29317, given the following type Flatten<T>:

type Flatten<T extends any[]> =
	{[P in keyof T]: T[P] extends Array<infer U> ? U : T[P]};

Would either or both of these be valid? (object is a supertype of any[])

// 1. covariant
const flat1: Array<object & not Array<any>> = get() as Flatten<object[]>;

// 2. contravariant
const flat1: Flatten<object[]> = get() as Array<object & not Array<any>>;

// Helper
declare function get(): any

Basically, does it follow math here or does it just break?

Edit: premature submission

@isiahmeadows Yeah, I was trying to model the return type of [...].flat(Infinity). It's currently not possible to do so because of the ban on recursive type aliases.

Bruce Pascoe (@fatcerberus) I know.

Wesley Wigham (@weswigham) Sorry, I forgot to mention you with my question.

TypeScript Bot (@typescript-bot) perf test this

Heya Wesley Wigham (@weswigham), I've started to run the perf test suite on this PR at 6c9e85c. You can monitor the build here. It should now contribute to this PR's status checks.

Update: The results are in!

Wesley Wigham (@weswigham)
The results of the perf run you requested are in!

We'll be building this feature off of #33050 now which includes some parts of this~