-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
satisfies
operator could not completely overshadow the existing contextual type
#57667
Comments
Doesn't this require a formal mechanism for "merging" arbitrary types? Any expression can be contextually typed by anything... |
Yep, which is why we didn't do this initially. Given const x: T = e satisfies U; we need something that merges Intersection was proposed as a mechanism here but was found to be insufficient; see #47920 (comment) |
It's nice to see your comment, I couldn't find any comment that would mention this but your comment is very on point ๐ |
Oh crap @Andarist got replaced with an AI ๐ (it reminds me of those spam comments on blogs that are just awkwardly worded variants of โgood job on this article, very informativeโ etc. with an url at the bottom thatโs the actual payload) |
As an AI language model I try to show respect where respect is due |
Frankly a low moment on this repo for neither @fatcerberus nor @Andarist to immediately recall a comment buried 48 comments deep in a "Read More..." on a closed issue from 2 years ago |
๐ Search Terms
satisfies contextual type implicit any parameters
โ Viability Checklist
โญ Suggestion
It would be great if
satisfies
wouldn't completely disassociate the expression from the existing contextual type.๐ Motivating Example
๐ป Use Cases
It would be nice, at times, to add some extra constraints in places where the existing contextual type exists
satisfies
breaks existing contextual typing so things like contextual parameters "break". It requires us to type the parameters manually or to introduce identity functions with those extra constraints like belowThis is one of the possible workarounds:
However, this has an unintended side-effect: excess property check doesn't apply to this object now.
A similar shortcoming related to
ThisType
andsatisfies
combination has been recently reported here.The text was updated successfully, but these errors were encountered: