-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Arguments cease to be assignable when parameter is broadened via conditional #52310
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
This side-swiping isn't necessary or helpful. Why bother? |
It's not intended as side-swiping but rather to try to provide for a little motivation on why this should be an issue worth fixing, instead of an issue to be dismissed like this, where behavior inconsistent with documentation won't get fixed because it just doesn't matter enough. Showing a connection to a larger goal the TypeScript project seems to make some public claims of supporting as a motivator for the project overall could be helpful and fixing this would bring the actual practice closer to the goal. Similarly, showing a connection between any project/task proposal and the motivation/mission of an organization/larger project is generally helpful to include in a document when the objective is to secure resources for that task to be completed. In the initial report, "bug/backlog" is a much more desired outcome than "closed wontfix/design choice." |
Right, and the stated implication that we're "fighting against" that goal, rather than toward it, is incredibly grating. |
Looking through the issues to try to find a duplicate before filing this one, most of what came up as potentially related was CLOSED WONTFIX, and I read through lots of comments to the effect of "this compiler behavior is wrong but it's hard to get right so we're not going to try to fix it and just close the issue report instead." That's also fairly consistent with my experience of responses to my own issue reports. TS's implementation differs so much from its advertised capabilities and attributes that even an application of only moderately low complexity requires going at least partway down this path way more often than reaching its conclusion; I see (and feel) individual engineers getting improper blame for incompetence when unable to get TS to work as easily as advertised because of compiler bugs and design choices. I definitely understand that some issues are very hard to fix, especially in the fully general sense that can cover 100% of all intended use cases. It seems likely that most issues available to be found in TypeScript now would be hard to fix: if they were easy to fix (and not just recently introduced), there's a pretty good chance they would already have been fixed, and wouldn't be outstanding issues. Even ones that seem like they should be easily fixable apparently have some hidden wrinkles that make them a lot harder. I also understand that some issues are not that important, though I don't think nearly as many issues where actual behavior diverges from documentation fall into that category as those who do the closing. Where I see divergences from stated goals actively dismissed as design choices, as I did when reviewing issues before this post, it does seem like there is some effort being expended to fight against those goals. One might hope (as I did) that calling some attention that, even with just a small comment buried near the end of a post, might lead to some of that effort being redirected to support the goal instead. |
It's extremely easy to find issues that people report and get treated as bugs and fixed in a timely manner. I'm not sure what it is you think the team is doing -- you can see the PRs that go through, you can see bugs getting triaged and fixed, and you can see product improvements in every release notes. At the end of the day I think you need to stop reading so much into Open vs Closed. If you want to fix a bug in something that's closed as Design Limitation, please go right ahead. I will not stop you; in fact I will cheer for you because you've done something we thought wasn't practical. The thing we're trying to communicate with Open vs Closed is "can this be fixed in a reasonable timeframe". We don't leave issues open if we don't think they can be fixed in a reasonable timeframe, because that creates wrong impressions in people reading those bugs. I don't want someone to see an "Open" issue on "TypeScript does not yet solve the halting problem to correctly typecheck this program" and think that TypeScript will be solving the halting problem in a future release. Maybe we will, but probably not, and the open/closed metadata is there to communicate that judgement. What you seem to be asking is that we discard that information and leave people with no idea of whether or not something can be fixed in the reasonable future, which is bad, because people should be able to look at these things and have reasonable expectactions. What you're trying to infer from it is "Does TypeScript care about its users". I can't stop you from taking these aggressive misreads of our planning metadata, but I'd really appreciate if you would do so on your own accord. |
Bug Report
🔎 Search Terms
conditional parameter assignable broader
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
Note: Dropping instances of ‘& string’ just results in a more complicated error message; it doesn’t change the core issue.
🙁 Actual behavior
actOnAttributeBroader
accepts a superset of the valid parameters ofactOnAttribute
.In this calling context, these two versions of the called function are equivalent, since all types in that context are limited to the more narrow set accepted by
actOnAttribute
. However, the TypeScript compiler doesn't even try to figure out that the one conditional type of this example code simplifies to the true branch in the context where the error is triggered, so there isn't actually a need to trigger an error. It triggers an error.🙂 Expected behavior
Making a reusable function more broadly reusable by accepting a broader set of parameter types should (a) possibly allow some calls that wouldn't work before the broadening to work, and (b) not cause any calls that were working fine before the broadening to suddenly start throwing Typescript compilation failures. Generic, reusable code should be considered a good thing and TypeScript should support that goal (as it seems to in the marketing that convinces technical executives to trigger conversions) rather than fight against it (as it does in practice with in-practice design choices and implementation defects, where this issue is an example).
Where Typescript correctly validates all parameters to a call to
actOnAttribute
and has enough information to determine which side of the conditional will apply (as it does here), it should do so and simplify the broader possibility of the reusable function down to the simpler original version where it can correctly validate types. There should be no error.The text was updated successfully, but these errors were encountered: