Repository navigation
TypeScript 5.1 Iteration Plan #53031
Description
Activity
- addedPlanningIteration plans and roadmappingIteration plans and roadmapping
on Feb 28, 2023 - pinned this issue
on Feb 28, 2023 DanielRosenwasser commented
on Mar 1, 2023 MemberAuthorMore actionsThe previous Iteration Plan for TypeScript 5.0 is available here.
How possible is it to investigate #13219 for release 5.1? This feature with 1200+ likes has been open since 2016.
While I understand that a full implementation of all throws clauses in all interfaces is breaking too much and may be a lot of manual work, just implementing support for this proposal for library authors and application developers may be enough. Once it sees adoption, adding support for core JS calls in a later release will be a lot smoother and could until then even be done using third-party or opt-in type declarations hosted on NPM.
/** * @description * Example function for demonstrating typed throws. * The function throws for values > 0.5 * @param seed Optional static number 0..1 to use for throw demonstration * @return Seed used for evaluation * @throws String with a user-readable error message */ function foo(seed?: number): number throws string { const num = seed ?? Math.random(); if (num > 0.5) { throw `Threshold: ${num.toString()}!`; } else { return num; } } // Example without throws-declaration: try { const result = await fetch('https://github.com'); //... } catch(e: unknown) { if (!(e instanceof TypeError)) return; // e is now of type TypeError console.error(e.message); } // Example with throws-declaration: try { console.log(foo()); } catch(e: string) { console.error(e); } // Example with throws-declaration, but not compiling: try { console.log(foo()); } catch(e: TypeError) {// Error: Type "TypeError" is never thrown in try-block. Possible types include "string" or "unknown"! console.error(e); }
Reacted by Rudolf Byker, Schrubitteflau, Elliot, Flavien Volken, Ian Luca, S.A.N, Emmanuel Hadoux, Jiayi Hu, Sasha Sorokin, Chana and 62 morePlease fix this #9619 issue existing from 2016
Reacted by Aviv NakarRyanCavanaugh commented
on Mar 1, 2023 MemberMore actionsFYI, how long an issue has been open is not really an input to the prioritization process. Otherwise C++ would have a garbage collector, since people have been asking for it since 1986.
Reacted by Jan Potoms, Caleb Jasik, Jake Bailey, Vladimir Grenaderov, Curt Grimes, Oleksandr Tarasiuk, Tristan Hessell , Charles Ancheta, Luís Rodrigues, Albin Larsson and 8 moreReacted by soc, Lorenzo, Tomáš Hübelbauer, Marek Lukáš and Kit SundeReacted by Chris Krycho, Kirill Groshkov, Daniel Schuba, Charles Ancheta, Toni Villena, Honza Hrubý, Vitaly, Sean Kelley, Degubi, Peter and 52 moreReacted by Maru Alka, 김회준, flexiworld and Aaron PetcoffReacted by eczn*FYI, how long an issue has been open is not really an input to the prioritization process. Otherwise C++ would have a garbage collector, since people have been asking for it since 1986.
I understand and agree with your point, but it’s too generic and unrelated to what I asked for. With all respect, asking C++ to become GC’ed is incomparable to asking TS built-in types to support ECMAScript spec.
Reacted by Rudolf Byker, Charles Ancheta, Maru Alka, reverofevil, Vitaly, 김회준, flexiworld, Eugene, Fabian Fetter, Ghost and 11 moreRyanCavanaugh commented
on Mar 1, 2023 MemberMore actionsMy point is just that, within a few years of using a programming language, one can conceive of probably 90% of the possible features you could ever add to that language. The fact that the vast majority of as-yet-unadded features date to ca.2016 is an unremarkable facet in light of TS being somewhat widely used starting in 2013.
Reacted by Laurent M and Ethan ResnickReacted by soc and GabrielReacted by socReacted by Felix Becker and Kostiantyn VRyan Cavanaugh (@RyanCavanaugh)
FYI, how long an issue has been open is not really an input to the prioritization process. Otherwise C++ would have a garbage collector, since people have been asking for it since 1986.
Yes, but it's not about the age and what's in line, but about if the amount of input is enough to warrant further inspection and maybe even inclusion. Your mentioning of C++ GCs doesn't answer my question! Can we pls stay on topic: What's next for TS, is typing for throws a candidate? If not, what's missing and what steps can we take to make progress!?
Reacted by Rudolf Byker, 김회준, flexiworld, Alexander Schumacher, Laurent M, Ghost, Benoit Pingris, Nicolas Leal and GabrielThere are also issues that are even older and have a lot of duplicates and are still not solved. I would love to see #299 fixed. It's even a three digit number.
But actually I doubt that it will ever be fixed.
Reacted by Maru Alka, Charles Lowell, William Lubelski, j4k0xb and Aaron CowieIs there any chance that #19139 could be considered for inclusion in 5.1 or maybe 5.2? 🙏
Reacted by Maru Alka, Michael Borislav, Eric R, ToreJuloe, Zeqiu Wu, Moritz Goertz, Matthieu Riegler, Anton Anderzén, S. Mahdi Mir-Ismaili and Kalil Smith-NuevelleTypeScript 5.1. 5 + 1 = 6. 6 is half of 12. There are 12 eggs in a dozen. TS 5.1 beta is coming out 2 days after easter. 12 + 2 = 14, but the Easter bunny will steal 1 egg so therefore there will be 13 eggs. A baker's dozen. But also 13 is an unlucky number. So TS 5.1 will be very unlucky for bakers and therefore should implement typing for all bread-related code to prevent bakers from losing their jobs
...okay, that's enough of that
Reacted by Rudolf Byker, Sreekanth Nagareddy, Richard Simpson, Hans Ott, Txema León and ConnorReacted by Daniel Rosenwasser, Toni Villena, Oliver Rose, James Bromwell, Danil Kochnev, Joshua J., Laurent M, Yamiteru, dnalborczyk and Pedro SanchezDid someone say bread 👀
Reacted by Bruce Pascoe, Maru Alka, Caleb Jasik, Daniel Rosenwasser, Toni Villena, Joshua J., Laurent M, Ghislain B., Tomáš Hübelbauer, Saman and 1 moreAnders Hejlsberg (@ahejlsberg) gave a very clear reasoning of why
throwsis not going to become a part of the language: because in order for those to work, you have to specify how higher-order functions handlethrowsfrom their functional arguments, and he doesn't think adding these annotations to every.d.tson DefinitelyTyped is viable.If anyone also remembers the interview and still has a link at hand, please, share.
how long an issue has been open is not really an input to the prioritization process
I should mention that C++ is developed by a committee, and the choice of features to be or not to be developed is done in the open. While there are Iteration Plans regularly posted here and even logs of Design Meetings, reasons behind feature discussion and implementation are completely opaque.
For example, JSX factories ticket was not only discussed previously, but also implemented. Then it was closed after 3 years without any review because it was "old". So in which situations age matters and in which it doesn't? Were JSX factories important in 2019, became unimportant afterwards, and then suddenly became important again in 2023? Well, we don't know anything about it.
Reacted by Daniel M., Heliks, Leandro Aguiar and equt78 remaining items
- added 15 commits that reference this issue
on Oct 8, 2024
This document outlines our focused tasks for TypeScript 5.1. It minimally indicates intent to investigate tasks or contribute to an implementation. Nothing is set in stone, but we will strive to complete these tasks in a reasonable timeframe.
gantt dateFormat YYYY-MM-DD TypeScript 5.0 Stabilization Period : 2023-02-24, 2023-03-10 TypeScript 5.1 Beta Development : 2023-02-27, 2023-04-14 TypeScript 5.1 RC Development : 2023-04-14, 2023-05-12 TypeScript 5.1 Stabilization Period : 2023-05-12, 2023-05-26 todayMarker stroke-width:5px,stroke:#0f0,opacity:0.5Compiler
usingDeclarationstypeRootsBehaviorslib.d.tsUpdatesLanguage Service
@paramSnippet CompletionsPerformance
.tsbuildinfoInfrastructure
Website