-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Meeting Notes, 3/11/2022 #48226
Comments
Could you please think about an alternative syntax for invariant. |
Another possibility could be to adopt the flow syntax: |
I agree with the above -which is also the Scala syntax for variance. |
We considered +/- but didn't like them compared to the keywords. |
having been a heavy scala user for 15 years now, i have no trouble at all to work with apart from that, they fit better into the general look and feel of typescript where a lot of things scala uses operators-like syntax for are expressed as keywords. |
I agree with the choice of the TypeScript team. |
Variance and Variance Annotations on Type Parameters
#48080 (comment)
#10717
(continued from #48209)
Playground Link
Could handle these better, but would break code.
Idea: variance annotations
Compare
T
by covariant rules:Compare
T
by contravariant rules:Compare
T
by invariant rules:Can help with documentation, correctness, perf.
Existing code that doesn't use these gets nothing out of it.
.d.ts
files if we can accurately measure?.d.ts
consumers!Would be nice if we could surface this information in quick info though.
Interface merging combines the variance annotations.
Variance annotations on generic signatures we don't allow - doesn't make sense.
Error messages?
Super
andSub
as the displayed names.Who would benefit the most from the perf aspect here?
typesVersions
to just give an instant perf boost to 4.7 users if this ships by then.Maybe urge caution.
in out
(invariant).Do we feel okay about the fact that two instantiations of the same type might be incompatible but structurally identical types would be compatible?
in out
future-proofs the API - kinda nice.So declaration emit?
This will force us to create a 4.7-based rift on DefinitelyTyped.
typesVersions
?Should we have some sort of support for JSDoc here?
How does this play with "Types as Comments"?
<
and>
JSDoc for variance annotations?
public
,private
,protected
.in
andout
.Our node factory APIs would need to take a breaking change.
NodeFlags
?Back to syntax!
/** @in @out */
The text was updated successfully, but these errors were encountered: