You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have issues with circularities when trying to measure variance of type parameters.
What if we had a way to tell the type system "if you need the variance when you hit a circularity, here it is"
typeFoo</** @in@out */T>={// ...};
Could also have some logic to say "ignore the circular references, but makes our results imprecise in the face of circularities (and makes them order-dependent).
Some don't like the reasons of variance assertions - nice escape hatch for some performance issues though.
Maybe some way of being able to record the measurements of T in Foo<T> that don't occur in the circular (in)direct references to Foo<T> by deferring those measurements. So when you're going into a loop, defer those measurements so that you have more information for later.
Need to find a way to record these locally, but not globally for other operations.
Two things really - algorithmic changes, and variance annotations. Mostly want to discuss annotations right now.
Do we want to have a flag that tells users when variance is possibly measured incorrectly?
Is it a diagnostics flag? Is it a strictness flag?
Would flag a LOT of types.
Right now have a prototype.
JSDoc.
Have an @in and @out and can combine with @in @out to specify invariant.
No checking whether they're the case.
Why "in and out"? Python uses explicit "contravariant"?
out means "I only use this in output/read positions"
in means "I only use this is input/write positions
How does this work with structurally similar types? For example, take a contravariant Box<T>:
Detecting Uncalled Function Statements
#47719
noImplicitReturns
- another lint-like rule.expect(name).not.toBeFalsy
foo.bar
- "oh, there's an error, doesbar
no exist? oh, no, it's just an unused expression"Variance and Variance Annotations on Type Parameters
#48080 (comment)
#10717
We have issues with circularities when trying to measure variance of type parameters.
What if we had a way to tell the type system "if you need the variance when you hit a circularity, here it is"
Could also have some logic to say "ignore the circular references, but makes our results imprecise in the face of circularities (and makes them order-dependent).
Some don't like the reasons of variance assertions - nice escape hatch for some performance issues though.
T
inFoo<T>
that don't occur in the circular (in)direct references toFoo<T>
by deferring those measurements. So when you're going into a loop, defer those measurements so that you have more information for later.Two things really - algorithmic changes, and variance annotations. Mostly want to discuss annotations right now.
Do we want to have a flag that tells users when variance is possibly measured incorrectly?
Right now have a prototype.
@in
and@out
and can combine with@in @out
to specify invariant.Why "in and out"? Python uses explicit "contravariant"?
out
means "I only use this in output/read positions"in
means "I only use this is input/write positionsHow does this work with structurally similar types? For example, take a contravariant
Box<T>
:What can you initialize this with?
Can't lie to make a write-only
Box
, otherwise things go off the rails.The text was updated successfully, but these errors were encountered: