Description Suggestion: treat in operator as type guard which asserts property existence #21732 in operator as type guard
Contrast with typeof foo.a === 'string' (which is not allowed) What would happen then?
Generate an intersection with { a: unknown } ? Same as the posted workaround Danger for unknown here becase "a" in x throws for x undefined / null / number / etc We should restrict this, if we do it, to object to avoid unexpected exceptions We could do it; should we? We already use in as a type guard when property absence is a psuedo-discriminant, which introduces some inconsistency if we do both Some discussion of how the in narrowing works Proposal is to only introduce this when the property is not present in any constituent of the right operand Many people pretend their types are sealed, which is fine if you're consistent about it Worth a try, accepting PRs Support higher order inferences for constructor functions #31116 Does what it says on the tin; same as we did for functions Takes a constructor and produces a function that calls the constructor, effectively Still subject to limitations around return type syntax What about mixins, as usual?
With new work, this can be better-supported Same as before, we'd be unable to correctly prevent name collisions This pattern doesn't support static members
Trade-off because now it's not a higher-order operation Why not just add another parameter with the same type? And treating that as a desugaring of the proposed version?
Now there's no place to put the type parameter Problem: Need to ensure that static members can't see the synthetic type parameters Cut for time Fix relations for instantiations of same generic signature #31029 Generic type alias produces erroneously compatible types #31006 Behavior as described is due to constraint erasure during type comparison
This is a correct shortcut as long as the constraint doesn't reference an outer type parameter Except for all the anys introduced causing problems What if we didn't erase them?
Found a couple bugs Sooooooo much more work to do! Ember's extensive use of keyof this means they're very reliant on bivariance
Now we generate a large number of unions when there are local type parameters styled-components v3 eats 4 GB of RAM and dies
v3 needs another workaround? What do we do about bug fixes that expose combinatorial explosions? Some possible perf fixes around variance measuring, but the general problem is... general Add a workaround to v3, fix ember, deliver this fix, and start looking harder at DT's performance characteristics Reactions are currently unavailable
You can’t perform that action at this time.
inoperator as type guard which asserts property existence #21732inoperator as type guardtypeof foo.a === 'string'(which is not allowed){ a: unknown }?unknownhere becase"a" in xthrows forxundefined / null / number / etcobjectto avoid unexpected exceptionsinas a type guard when property absence is a psuedo-discriminant, which introduces some inconsistency if we do bothinnarrowing worksanys introduced causing problemskeyof thismeans they're very reliant on bivariance