Allow self referential type aliases #33018
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
cc @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 pack this because why not And @typescript-bot run dt while I'm at it - considering this only affects what were error cases before.... |
|
Heya @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 @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 @weswigham, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running |
|
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. // note: might not be 100% correct
type Flattened<T> = T extends (infer U)[][] ? Flattened<U[]> : T; |
|
@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 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? ( // 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(): anyBasically, does it follow math here or does it just break? Edit: premature submission |
Closed
|
@isiahmeadows Yeah, I was trying to model the return type of |
|
@fatcerberus I know. @weswigham Sorry, I forgot to mention you with my question. |
|
@typescript-bot perf test this |
|
Heya @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! |
|
@weswigham Here they are:Comparison Report - master..33018
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We'll be building this feature off of #33050 now which includes some parts of this~ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #32967
I talked about this in the linked issue, but I think we already have pretty close to what we need in place to handle recursive type aliases - so this PR adds the parts we were missing.
With this you can now write:
and it will check like one may expect:
How it works
When we're creating a type reference, if we're looking to get a reference to a type alias type, we peek the circularity stack - if we see that we're already resolving that type, we return a (cached) "deferred substitution type". These substitution types can be handled exactly like any other substitution, the difference is in their implementation - their
substitutefield is not calculated until it is first accessed. (If this cuteness is a little over the top, a new type kind that functions like this could be added, but then we'd lose the free handling that already exists and would need to replumb a lot). So long as that substitute isn't immediately unwrapped, it can serve as a (reinstantiable!) placeholder for the type alias, functioning as a self-reference position.I'm opening this mostly to advance the discussion from #32967. Much of what we saw as blockers on recursive type aliases has, at this point, been handled in some way already (since conditionals and indexed accesses have inadvertently allowed some of the same mechanics, over time). Provided we want to commit to it, I think it's certainly reasonable for us to handle circular type aliases without substantial architectural change.