GeezerVison

with additional work it can be expanded to all type references.

To be clear, do you intend to resolve nested Promise types? Another, do you also intend to improve Array#{flat,flatMap}?

OK, so I expanded enough on this locally to try the

type HypertextNode = string | [string, { [key: string]: any }, ...HypertextNode[]];

const hypertextNode: HypertextNode =
    ["div", { id: "parent" },
        ["div", { id: "first-child" }, "I'm the first child"],
        ["div", { id: "second-child" }, "I'm the second child"]
    ];

example out (which is a motivator here), and the approach quickly hits its limits - namely, when we compare tuples, eventually we compare the array methods on the tuple, which have this types - this this type for the recursive alias then expands forever in instantiation, because getAnonymousTypeInstantiation eagerly applies type arguments to the object's captured type parameters (which un-defers them, which isn't an immediate issue, since their containing types now exist, but their structure is then problematic as instantiation doesn't keep any kind of "visited" stack, so will happily spin forever on the type (not knowing it needs to introduce a deferral anywhere). The un-deferal occurs because the getIndexTypeOfType call required for a rest parameter forces the type argument to the array to resolve before it's passed forward (while when the reference within the type argument is what is deferred, as in the other PR, this is no problem). I've opened this with the diff of what I've added

type ValueOrArray<T> = T | ValueOrArray<T>[];

So is this an alternative to #33018?

Wesley Wigham (@weswigham) Latest commit changes deferred type reference instantiation to use the same logic as anonymous types. This ensures that deferred type references continue to be deferred when instantiated, and it fixes the issues you were seeing with infinite instantiations. The motivating example

type HypertextNode = string | [string, Record<string, unknown>, ...HypertextNode[]];

const hypertextNode: HypertextNode =
  ["div", {id: "parent"},
    ["div", {id: "first-child"}, "I'm the first child"],
    ["div", {id: "second-child"}, "I'm the second child"]
  ];

now works as expected.

I still need to look at pulling in the other changes in your diff. The depth stuff was just a quick fix I put in place, I agree it isn't the correct solution.

Wesley Wigham (@weswigham) Printback now fixed by cherry picking some of your changes.

A bit more context on the latest commits... The instantiation logic for array and tuple type references is now similar to that of anonymous types and mapped types: We track which outer type parameters are in scope at the location of the reference and cache instantiations based on the type arguments of those outer type parameters. This means self-referential array and tuple types are no more expensive than self-referential object types.

is this an alternative to #33018?

I think this PR is the right way to solve the issue in #32967.

TypeScript Bot (@typescript-bot) perf test this

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the perf test suite on this PR at b18c70f. You can monitor the build here. It should now contribute to this PR's status checks.

Update: The results are in!

Anders Hejlsberg (@ahejlsberg)
The results of the perf run you requested are in!

Performance tests above show a worst case 5% check time increase and 10% memory consumption increase. That's a bit too expensive. With the latest commit we only defer type argument resolution for aliased array and tuple types. That should improve the numbers.

TypeScript Bot (@typescript-bot) perf test this

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the perf test suite on this PR at 8f3a917. You can monitor the build here. It should now contribute to this PR's status checks.

Update: The results are in!

Anders Hejlsberg (@ahejlsberg)
The results of the perf run you requested are in!

Rather than creating a(nother) location with an observable inline vs not inlined checking change (which we usually attempt to remove), would it really be so bad to only make the deferred type in cases where we find the type to be circular (ie, when we spot it on the circularity stack)? It's not the first place where we'd be doing something other than returning an errorType upon discovering a circularity - getTypeOfVariableOrParameterOrPropertyWorker has fallbacks on initial circularity in some circumstances already, and operating in that way would guarantee the perf and memory costs are near zero unless the feature is actually used.

Performance numbers now look great. Basically zero cost to cover the known scenarios!

would it really be so bad to only make the deferred type in cases where we find the type to be circular (ie, when we spot it on the circularity stack)?

That might be fine too, though we're already at zero cost for the feature. I like the current syntactic solution because it is easy to reason about when it kicks in. I wasn't aware that we do something other than return errorType upon discovering circularities. I'm not convinced that works in all cases because we potentially invalidate multiple circularity stack entries upon detecting a circularity, but we only do the non-errorType logic for some of them.

Yeah, I've wondered about that, too, but it has yet to come up. In any case, that's why I cautiously wrote the peek method instead in the other PR, to avoid invalidating the whole stack. But yeah, I know this roughly covers the important bits via syntax, and in that way, means there's always a way to make a thing work by transforming it into some kind of extracted alias, but we repeatedly got issues about how conditionals, when inlined, don't act the same (because if changes to distributivity, which is intentional), and any time an inlined type doesn't behave correctly because of an issue in variance, it's invariably reported. While this is easier to reason about implementation-wise, the behavior on usage is actually harder to justify, imo.

Doesn't seem to work:

type UnknownProps = Record<string, UnknownValues>
type UnknownValues = unknown | Record<string, UnknownProps>

Type alias 'UnknownProps' circularly references itself. ts(2456)
Type alias 'UnknownValues' circularly references itself. ts(2456)

playground link

Maybe I misunderstood it.

Joe Pea (@trusktr)

In the opening comment by Anders the definition of the new kinds of types that can be circularly referenced are defined as:

Instantiations of generic class and interface types (for example Array).
Array types (for example Foo[]).
Tuple types (for example [string, Foo?]).

The type Record is a reference to a mapped type from an alias, rather than an interface or class. For example, this works:

interface R<T> {
    [keys: string]: T;
}
type UnknownProps = R<UnknownValues>;
type UnknownValues = unknown | R<UnknownProps>;

It is still the case that TypeScript is not going to resolve arbitrary symbols because there needs to be some indication that the recursion in guarded by something.

Interesting. Also here's another way to write it:

type UnknownProps2 = {[K in string]: UnknownValues2};
type UnknownValues2 = unknown | Record<string, UnknownProps2>
type StartValues2 = {[K in string]: number | Array<number> | StartValues2};

const test2: UnknownProps = {a: 1, b: {c: 2}}

playground

I heard 4.1 will have better support for recursive types?

This is still throwing a circularity error in 4.0.5.

export type Unpromise<T> = T extends PromiseLike<infer U> ? Unpromise<U> : T;

EDIT:. That code works in 4.1.1-rc. Problem is already solved.

I do wish recursive types were possible with inference - for example, why can't this be type-hinted without explicitly having to declare a ServiceMap? It doesn't add any new information to what can be inferred from the return-types in the factory functions (line 29-30) so why should I have to declare this up front? The shape and return-types of the object I pass to Container can be inferred, so why doesn't that lead to a known type for $ in those function expressions? So long as $ doesn't affect the return-type of those closures, there's no "feedback loop" in the definitions of those types, so why doesn't that "just work"?

Rasmus Schultz (@mindplay-dk) yes I agree I don't see why it wouldn't be possible to infer that. Feel free to create an issue for this.

As far as I know, this code can not be implemented recursively. It can be done for the return type, but that would break the inference of the parameters.

// Only implemented as type
const guardAll = {} as <A, B, C, D, E, F, G, H, I, J, K>(
	guard1: RefineTypeGuard<unknown, A>,
	guard2?: RefineTypeGuard<A, B>,
	guard3?: RefineTypeGuard<B, C>,
	guard5?: RefineTypeGuard<C, D>,
	guard6?: RefineTypeGuard<D, E>,
	guard7?: RefineTypeGuard<E, F>,
	guard8?: RefineTypeGuard<F, G>,
	guard9?: RefineTypeGuard<G, H>,
	guard10?: RefineTypeGuard<H, I>,
	guard11?: RefineTypeGuard<I, J>,
	guard12?: RefineTypeGuard<J, K>
) => (value: unknown) => value is A & B & C & D & E & F & G & H & I & J & K


type RefineTypeGuard<A, B> = (
	value: A,
	...args: readonly unknown[]
) => value is B extends A ? B : never;

// Create new predicate by combining them in order
const isFoobar = guardAll(
        // Don't have to tell TypeScript what the type of val is, it is inferred from the last predicate
	(val): val is string => typeof val === 'string',
	(val): val is `foo${string}` => val.startsWith(val),
	(val): val is 'foobar' => val === 'foobar'
);
const test = {} as unknown;
if (isFoobar(test)) {
	test; // "foobar"
}

Nico Brinkkemper (@nicobrinkkemper) Is this the sorta thing you're looking for? Playground Link

Nico Brinkkemper (@nicobrinkkemper) Is this the sorta thing you're looking for? Playground Link

Not exactly. See this example and hover over the functions in guardAll and you can see that the predicate of the first is passed to the next and so forth

Playground Link

Nico Brinkkemper (@nicobrinkkemper) That's the purpose of ValidateValues in my playground link. It goes through the predicate values and fails if the next value is not a subtype of the previous. AFAIK this is the only way to do this kind of thing generically..you have to teach the compiler how to do that validation.

What I'm talking about is the limitation to infer the parameters of the Type Guard. In your playground link (which is nice don't get me wrong) you are forced to type your parameters. In my playground I don't have to specify them, and if you hover over them you see the type of the previous predicate. This would mean that any invalid function will be catched right there on the spot and it would show a red line under that specific offending function.

For example if I add a invalid function to the pipe in my playground example, it shows:

Argument of type '(val: `foo${string}`) => val is number' is not assignable to parameter of type 'PipedTypeGuard<`foo${string}`, number>'.
  Type predicate 'val is number' is not assignable to 'value is never'.

Ahh, I see now what you mean about the differences and why you might not be interested in that particular implementation. I have some similar code to that playground, and yeah the errors end up being moved to the if statements I use them in since { error: ...} is not a boolean expression and its caught by my ESLint configuration

With Record still causes error:

type Obj1 = Record<string, Obj1 | string> // error
type Obj = {
	[key: string]: Obj | string
}; // fine

I'm using TypeScript 4.5 and still get ts(2502) error.

Code:

const func = (test: Test) => ({ ...test });

interface Test {
  test: ReturnType<typeof func>;
}

Minimum reproducible code sandbox:

• https://codesandbox.io/s/laughing-turing-1jpis

Related issue:

• Error: referenced directly or indirectly in its own type annotation. ts(2502) wechaty/puppet#180