-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Design Meeting Notes, 2/27/2024 #57568
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
Comments
You can't safely make |
As was discussed in #57436, isn’t this impractical? If you’re writing an explicitly annotated type guard (as opposed to just letting it be inferred for simple cases e.g. in a |
The user journey we're concerned about is
|
That's definitely a failure mode, though to be fair it's also a failure mode with type guards today (minus step 1). It's the same story as for annotating return types, except that annotated return types are checked whereas type predicates are not. This user journey would argue that maybe they should be. Except that would be a much bigger, breakier change. I'd like to at least quantify how many existing explicit type predicates wouldn't check, see #57465 (comment). |
Triple-Slash Reference Emit/Preservation (motivated by
--isolatedDeclarations
)#57440
--isolatedDeclarations
is that the flag should not affect emit itself./// <reference >
directives?export * as fs from "fs"
./// <reference types="node" />
--isolatedDeclarations
is to say that when TypeScript would do this, it should emit an error. In other words, the user has to write it out explicitly.///
references that allows people to control whether the reference is preserved, elided, or whatever.///
refs as a holdover from a time long-past. Don't ascribe them more value than they deserve!/// <reference types="..." />
/// <reference paths="..." />
/// <reference paths="..." />
--isolatedDeclarations
, and gets turned on for everyone in 6.0--verbatimReferenceDirectives
, require this in--isolatedDeclarations
, change it in 6.0...--verbatimReferenceDirectives
in 6.0? 😂Inferring Type Predicate Signatures from Function Bodies
#57465
Motivating example.
Today that errors because the
filter
doesn't work.Solution is to explicitly make the signature a type predicate
PR makes it so these signatures can be automatically infer.
boolean
Analysis cost?
This has been a long-standing request - people really don't like that
filter
doesn't work.What happens when multiple variables get narrowed?
(x is number AND y is number)
can't guarantee that the variables aren't bothnumber
. Kind of hard to reason about.What broke?
Inability to express comparability bounds:
Inlining in Pyright.
Could argue that so many libraries that have their own
isNotNull
etc. exist only because function expressions can't narrow.In some ways this is way better because type predicates are not checked based on how you've narrowed! But inferring is actually way better!
What are the downsides?
!!x
?"Truthy
.The text was updated successfully, but these errors were encountered: