GeezerVison

TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this inline
TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) perf test faster

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the abridged perf test suite on this PR at 3799524. You can monitor the build here.

Update: The results are in!

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 3799524. You can monitor the build here.

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 3799524. You can monitor the build here.

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the diff-based community code test suite on this PR at 3799524. You can monitor the build here.

Update: The results are in!

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

Anders Hejlsberg (@ahejlsberg)
Great news! no new errors were found between main..refs/pull/48240/merge

In here it has been mentioned that:

For now, we'll have to accept that variance measurement for circular types is sometimes inaccurate and/or dependent on declaration order

So from what I get - with this PR here we are going to have a somewhat unpredictable behavior by default and to make it predictable we'll be able to use variance annotations introduced by this PR. Couldn't/shouldn't the problem be flipped though? Couldn't you go with predictable and safe behavior (although slow) and propose using those variance annotations as performance optimization?

I understand that some libraries out there might be hard/slow to upgrade and to start using those annotations but with the time that should become less of a concern and people will notice great slowdowns pretty soon and they should start helping library authors to migrate to this performance optimization. With typesVersions it should be possible to support older TS versions while introducing those perf hints for 4.7.

I'm worried that by accepting the random behavior now the community will get stuck with it forever - while if this would be treated as a perf optimization then most people would get great safety improvements immediately and out of the box.

Correct me if Im wrong but in here:

Likewise, attempting to mark T invariant

It should be “contravariant”

When variance annotations are present, the type checker doesn't need to measure variance.

hm, how measuring is different from what u check and for what u raise errors described in the thread? Since reporting “correct” errors would require full structural computation - shouldnt this be described here as a limitation for raising those errors? I mean - sometimes they just wont be raised and u will trust the user input, did i get this right?

Couldn't you go with predictable and safe behavior (although slow)

We considered it and we don't think it's feasible. An unknown number of code bases out there would be negatively impacted, in some cases quite dramatically. To wit, compilation of immutable.js slowed down 50x with the candidate PR. It's an awful experience when updating to the latest version of TypeScript all of a sudden hangs your build process. I'd love to do better, but for the moment we don't have other candidate solutions.

Also, it really is relatively rare that the current implementation gets variance measurement wrong. It requires types to be circularly dependent and to flip variance somewhere in the circularity. That happens, but it definitely isn't common.

I'm worried that by accepting the random behavior now the community will get stuck with it forever

The scenarios in which the issue occurs are rare and well understood, and we'll continue to think about ways in which we can improve accuracy of variance measurement without adversely affecting performance. Nothing prevents us from adopting a better algorithm in the future.

It should be “contravariant”

Indeed. Thanks for catching that, I have fixed it.

how measuring is different from what u check and for what u raise errors described in the thread?

Variance measurement is similar to variance annotation checking, but requires more checks. Specifically, we always perform at least two checks (subtype-to-supertype and supertype-to-subtype) to measure variance, and sometimes require a third check to distinguish bivariance from unwitnessed type parameters. In contrast, annotation checking requires only one check for co- or contravariance, and no check at all for invariance.

It seems variance annotations are ignored even when checking the same generic type

Yeah, variance annotations are only consulted when relating instantiations of type aliases for object, function, and constructor type literals and mapped types, so it is kind of meaningless to add variances annotations for other kinds of types. I think the best course of action is for us to error on attempts to do so. I will put up a PR to that effect.

this is interesting

I'm just dropping by to wonder if whoever came up with this was a C programmer back in the day who loved SAL? Because I sense a bit of SAL here 😉☺️

It seems variance annotations are ignored even when checking the same generic type

Yeah, variance annotations are only consulted when relating instantiations of type aliases for object, function, and constructor type literals and mapped types, so it is kind of meaningless to add variances annotations for other kinds of types. I think the best course of action is for us to error on attempts to do so. I will put up a PR to that effect.

Checking after diagnostics have been added it seems that it is still possible to define a parameter invariant even if the measured variance is either covariant or contravariant. Is this intended? It seems to me that given annotations are ignored in structural comparisons the only thing that make sense is to have them being strictly equal to the measured one

it is still possible to define a parameter invariant even if the measured variance is either covariant or contravariant. Is this intended?

Yes it's explicitly stated in OP

Invariance annotations (in out T) are never checked but simply assumed to hold. Thus, it is possible to assert invariance even when the actual usage of a type parameter is co- or contravariant.

it is still possible to define a parameter invariant even if the measured variance is either covariant or contravariant. Is this intended?

Yes it's explicitly stated in OP

Invariance annotations (in out T) are never checked but simply assumed to hold. Thus, it is possible to assert invariance even when the actual usage of a type parameter is co- or contravariant.

Yes, I am asking if it is still intended and an explanation of why that is ok

Yes, I am asking if it is still intended and an explanation of why that is ok

Yes. Part of the goal here is not just correctness, but performance. For many libraries causing slowdowns during typing (as in, typing in the editor), variance measurement accounts for a very large portion of the CPU time spent, so "skipping" checks when the author tells us what the result is going to be is a big performance win. Asserting invariance specifically means there's no possible soundness gap created as a result, since only fewer relations are allowed as a result.

Yes, I am asking if it is still intended and an explanation of why that is ok

Yes. Part of the goal here is not just correctness, but performance. For many libraries causing slowdowns during typing (as in, typing in the editor), variance measurement accounts for a very large portion of the CPU time spent, so "skipping" checks when the author tells us what the result is going to be is a big performance win. Asserting invariance specifically means there's no possible soundness gap created as a result, since only fewer relations are allowed as a result.

Thanks! I have definitely felt the pain in some scenarios, I agree there is no soundness gap from the structural perspective, there may be a perceived soundness gap when those annotations are ignored in structural fallback if there is a mismatch between the annotated variance and the actual variance but if the library authors are aware of it perf wins

Is TS going to emit variance annotations in .d.ts?

At the moment, the intent is to emit whatever you've written. If you leave a type parameter bare, we'll continue to leave it bare, which will mean that consuming modules will continue to infer the variance.

If you need to provide variance annotations for newer users, but need to provide an experience that gracefully degrades, you can use

• typesVersions
• downlevel-dts once Strip down variance annotations sandersn/downlevel-dts#73 is completed

At the moment, the intent is to emit whatever you've written.

Can I add a compiler flag or something to let typescript emit those variance annotations in .d.ts so it will automatically speed up the compilation?

Can I add a compiler flag or something to let typescript emit those variance annotations in .d.ts so it will automatically speed up the compilation?

Do you mean emitting the computed variance annotations?

The computed variances are more often than not much more complicated than the simple in/out/in out the annotations expose (mapped types and conditional types have odd assignability relationships!), and since writing a variance annotation that doesn't exactly match the measured variance can lead to surprising behavior, we leave it to users to annotate as they see necessary, and make that tradeoff consciously.

mapped types and conditional types have odd assignability relationships!

Would love to read a write-up about this! It could demystify some bits about the TS compiler for a lot of people

Should using the covariance out keyword to make the generic assigned to a property readonly?

Example:

• Flow: https://flow.org/try/#0C4TwDgpgBAyg9gWwsAFgSwHYHMoF4oDeAUFFAPRlQAqK0ARANR1QCGGGcwLwacGUtAE7QkbAM5RU0MILiRBoKGgnCWAEwC0fADYgSUBiwBcUMcEGYsAGiIBfANxFQkWImTpsAUW1jo+YqSGJmYW2FAAPlAYAK4IAEYQgjYOREQAxnxmkh5YJvBIqJZ4hKwmdLTa2nDMKRRQAGJVAO6slXBNElKsYmJoWBhIGMBR7VAJaSzRvlAABvnult6+M0R1ykoYahAQaqym0XHO0HAAZrPzhdgzI00AhOmZw5xCeW6XWEt+2ZaOq5QAQtFhhwWo1Rk00JUoIlZIIoHxWBgQN1ev1BsNgHBZiwZjY6r0MGloGhgAByCRiaJgMBwXy7TFjaAsKCqTQ6ZEyOSJUBEZ6JAB0zPwAFZ7EA

a is covariant and cannot be assigned to a number, or anything.

• Typescript: https://www.typescriptlang.org/play?#code/C4TwDgpgBAyg9gWwsAFgSwHYHMoF4oDeAUFFAIYBcUAzsAE6ZYA0RAvgNxGiSyLLrYAogBtq0fMVKUa9RlAA+UDAFcEAIwh0WHIkQDGcDLSipGVeElPY8hclQBEKCMOFx7UHQaPAocVJvM+KywRMRtgziIAeiioAEFqajQsDDlgOCgAAz8nOkzyUQykMiNyROTU63Ss4Mzo2IAhZR9M4IA6Mny0ahplMDA4MQATEwyNchkGbABCeqgAFXAIaj0GMB9qFDhlYRG9MmA9FBN0HooACiIczQ6bAFZ2IA

a can be assigned to a new value.

• Typescript with optional variance: https://www.typescriptlang.org/play?ts=4.7.0-dev.20220421#code/C4TwDgpgBAyg9gWwsAFgSwHYHMoF4oDeAUFFAIYBcUAzsAE6ZYA0RAvgNxGiSyLLrYAogBtqEADxwArsCgAVAHx5CJclTksORIgGM4GWlFSMq8JMezKCaqACIUEYcLi2oWvQdlxUEOqb4WWCJi4rQMlgA+UBhSCABGvkr4gZxEAPRpUACC1NRoWBiMRnBQAAbeDnSl5KIlSGQG5Ln5hZbAJaWBpemZAEIyZYEAdGTVaNQ0UmBgcGIAJsVQCeQ09IwAhD3y4BDUOgxgstQo0sILOmTAOihG6BMUABREFb4jygCs7EA

a can be assigned to a new value.

I just realized, there's no way to mark a parameter bivariant to skip variance measurements on types with bivariant parameters. Is there a fundamental reason variance measurement can't be avoided when there's a bivariant parameter, or would explicit variance annotations be a reasonable feature request?

Maybe I misunderstand but it seems like the only hope of reliably avoiding potentially infinite type errors with complex circular types is to explicitly annotate every type parameter so that TS won't perform variance measurement and we know there's no risk of accidentally crossing the threshold with slightly more complex types. So I wish I could also explicitly annotate bivariance.

I'm pretty sure I wasn't thinking and parameters aren't allowed to be bivariant...I was experimenting with adding variance annotations to ZodObject and have errors making the shape parameter parameter covariant, contravariant, and invariant, so I mistakenly assumed it needs to be bivariant but I must have needed to fix something else.