You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nicholai Main (@nmain) My 2¢, trivial for some magic for others, I would argue all build-in mapped and conditional types are trivial to write but that does not make them any less useful. Having a common set of types makes code easier to understand across projects. Omit is also simpler to understand for newer typescript devs and they don't have to do conditional type math when looking at a definition, they just care about the behavior of the type.
Reacted by Christian, Javier Gonzalez, Basarat Ali Syed, Dimitri B., ulrichb, Sindre Sorhus, Braden Snell, Mark Dalgleish, Esa-Matti Suuronen, Alexander Kuznetsov and 21 more
Reacted by Basarat Ali Syed and Derk-Jan Karrenbeld
Reacted by Titian Cernicova-Dragomir, Mark Dalgleish, Jiri Spac, Sasha Koss, Alexander Kuznetsov, Sebastian Meier, Steven, James P, Matthew Leffler, Richard Simpson and 20 more
Totally agree, I end up declaring that Omit type in almost every project.
It's like Record<string, string> could be written { [k: string]: string}. I prefer the Record helper, same feeling about this one.
Reacted by Ifiok Jr., Pascal Iske, Christophe Hurpeau, ExE Boss, c69 and Chang Wang
I've used Omit in every single project and every single time I have to look it up, because Pick<T, Exclude<keyof T, K>> isn't trivial to recall; if many people use it in every project, it make sense to make it part of lib.d.ts right?
It's like Record<string, string> could be written { [k: string]: string}. I prefer the Record helper, same feeling about this one.
We did not include the Omit<T, K> type because it is trivially written as Pick<T, Exclude<keyof T, K>>
I'm not so sure about the triviality of it, especially for new TS devs, but IMHO this isn't a good reason for not including Omit, to me it feels like saying that if I have this code:
returncollection.map(item=>item.foo());
I don't really need map because it's trivial to do the same with forEach:
Reacted by Esa-Matti Suuronen, Titian Cernicova-Dragomir, Steven, Sindre Sorhus, Christian Rackerseder, Jørgen Arnor G. Lom, Jahan Addison, Tiger Oakes, a1300, ExE Boss and 1 more
Reacted by Fabio Spampinato, Christian, Steven, Derk-Jan Karrenbeld, Jørgen Arnor G. Lom, Jahan Addison, OctoD and ExE Boss
The naming of this is rather unfortunate. I mean to say, what exactly is the difference between the words "Omit" and "Exclude"? They are essentially synonyms with a minor nuance.
The definition we have used is ExcludeProperty.
/** * Exclude from T those types that are assignable to U */typeExclude<T,U>=TextendsU ? never : T;/** * From T remove the properties K * E.g. ExcludeProperty<{ a: number, b: string }, 'b'> => { a: number } */typeExcludeProperty<T,KextendskeyofT>=Pick<T,Exclude<StringKeyOf<T>,K>>;
Activity
j-oliveras commentedon Mar 18, 2019
Duplicate of #19569?
weswigham commentedon Mar 18, 2019
Not really? That was back when there was only a hairy mapped-type based definition of
Omitwhich we didn't particularly like, so didn't want to add.nmain commentedon Mar 19, 2019
Eventually that issue was closed after conditional types were added. Anders Hejlsberg (@ahejlsberg) made #21847 and said:
dragomirtitian commentedon Mar 19, 2019
Nicholai Main (@nmain) My 2¢, trivial for some magic for others, I would argue all build-in mapped and conditional types are trivial to write but that does not make them any less useful. Having a common set of types makes code easier to understand across projects.
Omitis also simpler to understand for newer typescript devs and they don't have to do conditional type math when looking at a definition, they just care about the behavior of the type.sindresorhus commentedon Mar 20, 2019
I personally use
Omitmuch more often than the other built-in helper types.jeremiergz commentedon Mar 21, 2019
Totally agree, I end up declaring that
Omittype in almost every project.It's like
Record<string, string>could be written{ [k: string]: string}. I prefer theRecordhelper, same feeling about this one.SleeplessByte commentedon Mar 21, 2019
I've used
Omitin every single project and every single time I have to look it up, becausePick<T, Exclude<keyof T, K>>isn't trivial to recall; if many people use it in every project, it make sense to make it part oflib.d.tsright?That's not the same; and it's not even close.
jeremiergz commentedon Mar 21, 2019
How so? Isn't it better to explain your train of thought when you say someone's wrong?...
SleeplessByte commentedon Mar 21, 2019
Sorry, you're right -- and my thoughts were wrong anyway. I would even say that omit is far more difficult than record!
What I should have said is that it's better to compare
Record<keyof K, string>to{ [P in K]: string }.fabiospampinato commentedon Mar 22, 2019
The docs' reasoning about this is:
I'm not so sure about the triviality of it, especially for new TS devs, but IMHO this isn't a good reason for not including Omit, to me it feels like saying that if I have this code:
I don't really need
mapbecause it's trivial to do the same withforEach:I mean yeah, it's trivial, but am I supposed to write such ugly code every time or am I supposed to redefine
mapevery time?DanielRosenwasser commentedon Apr 4, 2019
This is now 3.5-bound! 🚀
You can try it out with our next nightly release.
leidegre commentedon Apr 7, 2019
For those curious how the
Omittype is used, you can find that information here.NoelAbrahams commentedon Apr 9, 2019
The naming of this is rather unfortunate. I mean to say, what exactly is the difference between the words "Omit" and "Exclude"? They are essentially synonyms with a minor nuance.
The definition we have used is
ExcludeProperty.sindresorhus commentedon Apr 10, 2019
For everyone watching this issue, note that the
Omittype that was added is not the strict one suggested here. See: #30825.