GeezerVison is showing github.com — Exact Types · Issue #12936 · microsoft/TypeScript
DescriptionThis is a proposal to enable a syntax for exact types. A similar feature can be seen in Flow (https://flowtype.org/docs/objects.html#exact-object-types), but I would like to propose it as a feature used for type literals and not interfaces. The specific syntax I'd propose using is the pipe (which almost mirrors the Flow implementation, but it should surround the type statement), as it's familiar as the mathematical absolute syntax.
interface User {
username: string
email: string
}
const user1: User = { username: 'x', email: 'y', foo: 'z' } //=> Currently errors when `foo` is unknown.
const user2: Exact<User> = { username: 'x', email: 'y', foo: 'z' } //=> Still errors with `foo` unknown.
// Primary use-case is when you're creating a new type from expressions and you'd like the
// language to support you in ensuring no new properties are accidentally being added.
// Especially useful when the assigned together types may come from other parts of the application
// and the result may be stored somewhere where extra fields are not useful.
const user3: User = Object.assign({ username: 'x' }, { email: 'y', foo: 'z' }) //=> Does not currently error.
const user4: Exact<User> = Object.assign({ username: 'x' }, { email: 'y', foo: 'z' }) //=> Will error as `foo` is unknown.This syntax change would be a new feature and affect new definition files being written if used as a parameter or exposed type. This syntax could be combined with other more complex types.
type Foo = Exact<X> | Exact<Y>
type Bar = Exact<{ username: string }>
function insertIntoDb (user: Exact<User>) {}Apologies in advance if this is a duplicate, I could not seem to find the right keywords to find any duplicates of this feature.
Edit: This post was updated to use the preferred syntax proposal mentioned at #12936 (comment), which encompasses using a simpler syntax with a generic type to enable usage in expressions. Reacted by John Reilly, Mohsen Azimi, Maksym, Giulio Canti, Sean Vieira, Chris, Igor Oleinikov, Marco Schmidlin, Ben Southgate, Leon Adler and 1283 more Reacted by Hans Ott, bl-ue, qb-vajahath, Dmitrijs Balcers, Alexandre Annic, Justin Leider, Felipe S. S. Schneider, Daniel, Bryan Green, marcin-wlodarczyk and 58 more Reacted by Matt Shwery, sobolevn, Vajahath Ahmed, Devin Rhode, SPGoding, Erick Riva, Attila Večerek, S. Tarık Çetin, Martin Olsansky, Jonas Hübotter and 106 more Reacted by yossarian, Marquitos, sobolevn, Vajahath Ahmed, Devin Rhode, Erick Riva, Dmitrii Kartashev, S. Tarık Çetin, Martin Olsansky, Andy Barron and 65 more Reacted by David Blass, Bakhtier Gaibulloev, Michal Kalita, Matthias Kunnen, Paul Damnhorn, Andy Edwards, GrayStrider, Daria Moreno-Gogoleva, Nathan Broadbent, Sean Blonien and 76 more ActivityHerringtonDarkholme commented on Dec 15, 2016 I would suggest the syntax is arguable here. Since TypeScript now allows leading pipe for union type.
class B {}
type A = | number |
BCompiles now and is equivalent to type A = number | B, thanks to automatic semicolon insertion.
I think this might not I expect if exact type is introduced. Reacted by Mathieu CAROFF, Clarity, Ben Gotow, bl-ue, Dmitriy Kovel, Mikkel Lund, Nathan Baum and Ahmed Abdel-Aziz Reacted by Benji, Umed Khudoiberdiev, sean, TomScavo, Rodrigo Roa Rodríguez, Leon Adler, Brian Frichette, Eon, Bryson Bennett and Emmanuel Meric de Bellefon normalser commented on Dec 15, 2016 Not sure if realted but FYI #7481 DanielRosenwasser commented on Dec 15, 2016 If the {| ... |} syntax was adopted, we could build on mapped types so that you could write
type Exact<T> = {|
[P in keyof T]: P[T]
|}and then you could write Exact<User>. Reacted by Herrington Darkholme, Alexander Rusakov, Tingan Ho, Josh Abernathy, John Reilly, Blake Embrey, jwbay, Sean Vieira, Chiri Vulpes, Chris Krycho and 97 more Reacted by Mohsen Azimi, ZpdDG4gta, aikrasnov, kenjiru, Chris Miemiec, Tarık İNCE, Zihang Qi, Ben, Adrian, pierre and 9 more Reacted by techtic-anil, Emanuel Tesař, lm-noshiro, Marvin, Package, Hans Ott, bl-ue, Felipe S. S. Schneider, treesentinl, Alex and 2 more joshaber commented on Dec 15, 2016 This is probably the last thing I miss from Flow, compared to TypeScript.
The Object.assign example is especially good. I understand why TypeScript behaves the way it does today, but most of the time I'd rather have the exact type. Reacted by hardfist, Nathan Broadbent, Erick Riva, IS-Kuan, Omeid Matten, Hans Ott, Kay Gosho, bl-ue, S. Tarık Çetin, Emanuel Lindström and 33 more blakeembrey commented on Dec 15, 2016 ContributorAuthor More actions rotemdan commented on Dec 17, 2016 What if I want to express a union of types, where some of them are exact, and some of them are not? The suggested syntax would make it error-prone and difficult to read, even If extra attention is given for spacing:
|Type1| | |Type2| | Type3 | |Type4| | Type5 | |Type6| Can you quickly tell which members of the union are not exact?
And without the careful spacing?
|Type1|||Type2||Type3||Type4||Type5||Type6| (answer: Type3, Type5) Reacted by Leon Adler, Kirill Agalakov, Aluan Haddad, Michał Lytek, Mark Penner, Kris Kaczor, Chris Miemiec, inburek, Sam Hunt, resynth1943 and 26 more blakeembrey commented on Dec 17, 2016 ContributorAuthor More actions Rotem Dan (@rotemdan) See the above answer, there's the generic type Extact instead which is a more solid proposal than mine. I think this is the preferred approach. rotemdan commented on Dec 17, 2016 There's also the concern of how it would look in editor hints, preview popups and compiler messages. Type aliases currently just "flatten" to raw type expressions. The alias is not preserved so the incomperhensible expressions would still appear in the editor, unless some special measures are applied to counteract that.
I find it hard to believe this syntax was accepted into a programming language like Flow, which does have unions with the same syntax as Typescript. To me it doesn't seem wise to introduce a flawed syntax that is fundamentally in conflict with existing syntax and then try very hard to "cover" it.
One interesting (amusing?) alternative is to use a modifier like only. I had a draft for a proposal for this several months ago, I think, but I never submitted it:
function test(a: only string, b: only User) {};That was the best syntax I could find back then.
Edit: just might also work?
function test(a: just string, b: just User) {};(Edit: now that I recall that syntax was originally for a modifier for nominal types, but I guess it doesn't really matter.. The two concepts are close enough so these keywords might also work here) Reacted by Aluan Haddad, Gitowiec, Aleksej Kuzmichev, resynth1943, bl-ue, Anton Polischuk, Elliot, Nicholas Estrada, centigrade-julian-lang, Nicolas Pelletier and 4 more rotemdan commented on Dec 19, 2016 I was wondering, maybe both keywords could be introduced to describe two slightly different types of matching:
just T (meaning: "exactly T") for exact structural matching, as described here.only T (meaning: "uniquely T") for nominal matching.
Nominal matching could be seen as an even "stricter" version of exact structural matching. It would mean that not only the type has to be structurally identical, the value itself must be associated with the exact same type identifier as specified. This may or may not support type aliases, in addition to interfaces and classes.
I personally don't believe the subtle difference would create that much confusion, though I feel it is up to the Typescript team to decide if the concept of a nominal modifier like only seems appropriate to them. I'm only suggesting this as an option.
(Edit: just a note about only when used with classes: there's an ambiguity here on whether it would allow for nominal subclasses when a base class is referenced - that needs to be discussed separately, I guess. To a lesser degree - the same could be considered for interfaces - though I don't currently feel it would be that useful) Reacted by resynth1943, monnef, David Rogers, bl-ue, Vitaly Suhanov, Christian Schuff, Nicholas Estrada, HimeHina, WilliamConnatser, Jordan Harris and 2 more ethanresnick commented on Jan 8, 2017 This seems sort of like subtraction types in disguise. These issues might be relevant: #4183 #7993 blakeembrey commented on Jan 8, 2017 ContributorAuthor More actions johnnyreilly commented on Jan 12, 2017 This would be exceedingly useful in the codebase I'm working on right now. If this was already part of the language then I wouldn't have spent today tracking down an error.
(Perhaps other errors but not this particular error 😉) mohsen1 commented on Feb 17, 2017 I don't like the pipe syntax inspired by Flow. Something like exact keyword behind interfaces would be easier to read.
Reacted by Nicholas Steicke, Marin Marinov, normalser, ZpdDG4gta, Leon Adler, Michał Lytek, Boris Cherny, Corbin Crutchley, Adam Horak, Christopher Dignam and 74 more Reacted by Alex D and Patrick Wheeler Reacted by George Taylor, cobalt, bl-ue, Andreas Herd and Andrew Smiley RobertSandiford commented on Nov 27, 2025
We run into this constantly.
I'm curious, why the holdout here? The example provided is opt in (could be specified as a default in tsconfig and individually opted out as well).
Is there some technical reason this is not being done or are the TS maintainers opposed to this? If it is technical, does the v7 release and go implementation fix it?
My main concern about it is format wars. An exact object can't be passed to a loose object slot, and a loose object can't be passed to an exact object slot. (The first can be solved by duplicating the object, although that can be non trivial when considering nested objects including recursive objects and objects containing instances of external classes. The second can be solving by picking the relevant fields and copying those to a new objects - but again it can become complicated with deep objects.)
This leads to some libraries requiring exacts, while others require loose objects, and if you try to use mismatching libraries together it could be painful. It's reminding me of CJS + ESM again. I think it's pretty reasonable to try to avoid that.
It's generally fairly simply to approximate exact objects with a loose object plus a list of known keys, where only those properties are accessed. Although exact objects sound appealing, I think the reality is much less clear. There's a lot to be said for staying with a single paradigm.
That aside, there doesn't seem to be a huge amount of active development going on - but it's open source, so you can contribute if you care enough about it. Reacted by Andy Edwards, Noah Sherwin, Wendy Fouchter and VimHax AntonVoronezh commented on Jan 22, 2026 TypeScript is like a friend who says "Bring whatever!" to a party. You ask for a User, it accepts a User + a KitchenSink. We've wanted a "No Plus Ones" policy since 2016.
The "Exorcist" Fix:
type Exact<T, S> = { [K in keyof T]: K extends keyof S ? T[K] : never };My Proposal:
The "I Mean It" Operator (!):
const u: !User = { name: "Bob", extra: 123 }; // ❌ Error!Let's make TS a bit more "rude" for our own safety!
ExtraProps=Never Reacted by Christian Svensson and Yasin Akimura Reacted by Danny Martini Reacted by Jordan Harris, Adrian and Philipp Beau adrian-gierakowski commented on Jan 22, 2026
The "I Mean It" Operator (!):
I like it! isc30 commented on Jan 23, 2026 The Exact util can also be written like this:
type Exact<T extends object> = T & {
[K in Exclude<PropertyKey, keyof T>]?: never
}Reacted by Claudia Meadows zakhenry commented on Jan 24, 2026 !User reads as "not User" to me, especially for those familiar with Rust syntax e.g. !Send means a type that does not implement Send.
Reacted by Omer Mecitoglu and Robbie Speed fxdave commented on Jan 24, 2026
!User reads as "not User" to me, especially for those familiar with Rust syntax e.g. !Send means a type that does not implement Send.
Rust typesystem is not that dynamic though. Rust has nominal typing, TS has structural typing.
In Rust struct A {} and struct B {} is not the same.
In TS type A = {}, and type B = {} are the same.
Also in Rust you cannot dynamically create new types.
In TS, if you need something like this you most likely be able to constraint the type to your specific case like:
type Response = { result: 'success', message: string } | { result: 'error', errorCode: number }
type SuccessResponse = Response & { result: 'success' }
type NotSuccess = Exclude<Response, SuccessResponse>So it's unlikely that !Type (as not Type) would ever be in typescript. To me it more likely resembles with the "exclude undefined" operator error.message!. Which is kinda "I mean it". reverofevil commented on Jan 24, 2026 TS has no typing. It's a static analyzer, not a typed programming language, per its own description.
The correct implementation of "exact objects" already exists in OCaml. Copying the implementation wouldn't take a decade if it was even considered by language devs.
Please read comments before adding more to the thread. There are over 600 of them, and this thread doesn't really need more. Reacted by David Judge, Andy Edwards and snarbles2 dead-claudia commented on Jan 25, 2026
The Exact util can also be written like this:
type Exact<T extends object> = T & {
[K in Exclude<PropertyKey, keyof T>]?: never
}
TypeScript does not have negated types, so that doesn't work. type E = Exact<T> per that definition resolves to just this:
type Named = {
foo: "bar"
}
type StringMap = {
[P in string]: "bar"
}
type NumberMap = {
[P in number]: "bar"
}
type SymbolMap = {
[P in symbol]: "bar"
}
// Exact<Named>
type ExactNamed = {
[P in string | number | symbol]?: never
}
// Exact<StringMap>
type ExactNamed = StringMap & {
[P in number | symbol]?: never
}
// Exact<NumberMap>
type ExactNamed = NumberMap & {
[P in string | symbol]?: never
}
// Exact<SymbolMap>
type ExactNamed = SymbolMap & {
[P in string | number]?: never
}trusktr commented on Jan 27, 2026 This feature is needed for preventing program errors.
For example this can improve and provide proper types for iteration of features like Object.keys/entries(). Reacted by Peter Jaško Reacted by RobertSandiford dead-claudia commented on Jul 19, 2026 Massimiliano Brighindi [email protected] (@Tuttotorna) That requires a runtime component to do correctly and safely. Anything that requires a runtime component would be a non-starter for the TS team, who's long historically rejected such proposals. And for something like this, a runtime component would also generate a ton of call-site boilerplate and possibly cause perf issues in some areas.
Also, exact types are not for stuff like database objects. It's for stuff like socket messages and configuration objects, where objects are often legitimately constrained in some way, and where if you actually needed to add fields, you might need to rewrite a bunch of code anyways whether the type was open-ended or not. Reacted by Christian Svensson codpro2005 commented on Sep 1, 2026 While TypeScript is unfortunately missing a native concept of exact object types like Flow has, we may at least use a guard in the meantime.
type Exact<T, TTarget> = TTarget extends unknown
? keyof T extends keyof TTarget
? TTarget
: never
: never
;The idea is to narrow the target by distributively filtering out its members which don't contain all of T's keys.
Try it in the playground →
For actual values, we can define a helper function that applies a guard like the following:
const exact = <TTarget extends unknown>() => <T extends Exact<T, TTarget>>(value: T) => value; Try the helper in the playground →
Deep implementation
Here's an attempt at handling exactness recursively while walking through records, arrays and functions (though those are likely least robust):
type As<T, _Infer extends T> = unknown;
type ValueOf<T> = T[keyof T];
type Variance = 'covariant' | 'contravariant';
type NegateVariance<T extends Variance> = Exclude<Variance, T>;
type ToRelation<T extends Record<Variance, unknown>, TVariance extends Variance> = {
sub: T[TVariance],
super: T[NegateVariance<TVariance>]
};
type ExactDeepInternal<T, TTarget, TVariance extends Variance> = (unknown extends As<
{[K in keyof TTarget]: ExactDeepInternal<T[K & keyof T], TTarget[K], TVariance>},
infer TargetRecord
>
? TTarget extends unknown[]
? number extends TTarget['length']
? {[K in keyof T]: ExactDeepInternal<T[K], TTarget[number], TVariance>}
: TargetRecord
: TTarget extends Record<keyof never, unknown>
? TargetRecord
: TTarget extends (...args: never[]) => unknown
? unknown extends As<
T extends ((...args: never[]) => unknown)
? T
: never
,
infer TFunc
>
? ((
...args: Parameters<TFunc> extends never
? Parameters<TTarget>
: ExactDeepInternal<Parameters<TFunc>, Parameters<TTarget>, NegateVariance<TVariance>> extends infer Args extends unknown[]
? Args
: never
) => ExactDeepInternal<ReturnType<TFunc>, ReturnType<TTarget>, TVariance>)
: never
: TTarget
: never
) extends infer Target
? Target extends Record<keyof never, unknown>
? unknown extends As<
ToRelation<{
covariant: T,
contravariant: Target
}, TVariance>,
infer Relation
>
? ValueOf<{
[K in keyof Relation['sub']]: Omit<Relation['sub'], K> extends infer SuperCheck extends Relation['super']
? K extends keyof (SuperCheck & Relation['super'])
? never
: unknown
: never
}> extends undefined
? Target
: {
covariant: never,
contravariant: unknown
}[TVariance]
: never
: Target
: never
;
type ExactDeep<T, TTarget> = ExactDeepInternal<T, TTarget, 'covariant'>;Try it in the playground →
Note: I haven't done any deeper tests so use with caution.
ClementValot commented on Sep 1, 2026 Copy-pasting in whatever your favorite chatbot had to say about that and postfacing it with "I haven't tested it" is peak open-source contribution, no notes 👌
EDIT: Giving you the benefit of the doubt but please understand that this combo of wording, formatting and opaque code has people on edge :')
Also at a glance this type seems costly in terms of tsc performance, due to the deepness of the ternaries, on top of the recursion. Splitting it into named types could alleviate some of the perf overhead as well as make it easier to understand. Reacted by chocolateboy and Antonio Salazar Cardozo Reacted by Christian Svensson, lasamlai and Stephen Pittman codpro2005 commented on Sep 1, 2026 Clément Valot (@ClementValot) Everything was written by me. I was only saying that I haven't tested for any bigger nested objects 😅
Edit: I realize you probably only looked through the post itself. Worth noting that I deliberately tried to keep it compact so it doesn't pollute the issue. The actual playground links contain test cases and a couple notes!
Edit 2:
Giving you the benefit of the doubt but please understand that this combo of wording, formatting and opaque code has people on edge :')
I understand. Nowadays it's hard to tell authentic work apart from vibecoded solutions. One could write a custom skill to get rid of common AI indicators. Partially my fault too, as I sounded relatively unconfident given the effort that went into this.
Also at a glance this type seems costly in terms of tsc performance, due to the deepness of the ternaries, on top of the recursion. Splitting it into named types could alleviate some of the perf overhead as well as make it easier to understand.
That's fair. I admittedly have no experience when it comes to benchmarking and my style of coding is kind of cursed. This served more as a "proof of concept". BinToss commented on Sep 1, 2026
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|