Exact Types

[blakeembrey]

This 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.

[HerringtonDarkholme]

I would suggest the syntax is arguable here. Since TypeScript now allows leading pipe for union type.

class B {}

type A = | number | 
B

Compiles 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.

[normalser]

Not sure if realted but FYI #7481

[DanielRosenwasser]

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>.

[joshaber]

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.

[blakeembrey]

@HerringtonDarkholme Thanks. My initial issue has mentioned that, but I omitted it in the end as someone would have a better syntax anyway, turns out they do 😄

@DanielRosenwasser That looks a lot more reasonable, thanks!

@wallverb I don't think so, though I'd also like to see that feature exist 😄

[rotemdan]

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)

[blakeembrey]

@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]

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)

[rotemdan]

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)

[ethanresnick]

This seems sort of like subtraction types in disguise. These issues might be relevant: #4183 #7993

[blakeembrey]

@ethanresnick Why do you believe that?

[johnnyreilly]

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]

I don't like the pipe syntax inspired by Flow. Something like exact keyword behind interfaces would be easier to read.

exact interface Foo {}

[blakeembrey]

@mohsen1 I'm sure most people would use the Exact generic type in expression positions, so it shouldn't matter too much. However, I'd be concerned with a proposal like that as you might be prematurely overloading the left of the interface keyword which has previously been reserved for only exports (being consistent with JavaScript values - e.g. export const foo = {}). It also indicates that maybe that keyword is available for types too (e.g. exact type Foo = {} and now it'll be export exact interface Foo {}).

[mohsen1]

With {| |} syntax how would extends work? will interface Bar extends Foo {| |} be exact if Foo is not exact?

I think exact keyword makes it easy to tell if an interface is exact. It can (should?) work for type too.

interface Foo {}
type Bar = exact Foo

[basarat]

Exceedingly helpful for things that work over databases or network calls to databases or SDKs like AWS SDK which take objects with all optional properties as additional data gets silently ignored and can lead to hard to very hard to find bugs 🌹

[blakeembrey]

@mohsen1 That question seems irrelevant to the syntax, since the same question still exists using the keyword approach. Personally, I don't have a preferred answer and would have to play with existing expectations to answer it - but my initial reaction is that it shouldn't matter whether Foo is exact or not.

The usage of an exact keyword seems ambiguous - you're saying it can be used like exact interface Foo {} or type Foo = exact {}? What does exact Foo | Bar mean? Using the generic approach and working with existing patterns means there's no re-invention or learning required. It's just interface Foo {||} (this is the only new thing here), then type Foo = Exact<{}> and Exact<Foo> | Bar.

[RyanCavanaugh]

We talked about this for quite a while. I'll try to summarize the discussion.

Excess Property Checking

Exact types are just a way to detect extra properties. The demand for exact types dropped off a lot when we initially implemented excess property checking (EPC). EPC was probably the biggest breaking change we've taken but it has paid off; almost immediately we got bugs when EPC didn't detect an excess property.

For the most part where people want exact types, we'd prefer to fix that by making EPC smarter. A key area here is when the target type is a union type - we want to just take this as a bug fix (EPC should work here but it's just not implemented yet).

All-optional types

Related to EPC is the problem of all-optional types (which I call "weak" types). Most likely, all weak types would want to be exact. We should just implement weak type detection (#7485 / #3842); the only blocker here is intersection types which require some extra complexity in implementation.

Whose type is exact?

The first major problem we see with exact types is that it's really unclear which types should be marked exact.

At one end of the spectrum, you have functions which will literally throw an exception (or otherwise do bad things) if given an object with an own-key outside of some fixed domain. These are few and far between (I can't name an example from memory). In the middle, there are functions which silently ignore
unknown properties (almost all of them). And at the other end you have functions which generically operate over all properties (e.g. Object.keys).

Clearly the "will throw if given extra data" functions should be marked as accepting exact types. But what about the middle? People will likely disagree. Point2D / Point3D is a good example - you might reasonably say that a magnitude function should have the type (p: exact Point2D) => number to prevent passing a Point3D. But why can't I pass my { x: 3, y: 14, units: 'meters' } object to that function? This is where EPC comes in - you want to detect that "extra" units property in locations where it's definitely discarded, but not actually block calls that involve aliasing.

Violations of Assumptions / Instantiation Problems

We have some basic tenets that exact types would invalidate. For example, it's assumed that a type T & U is always assignable to T, but this fails if T is an exact type. This is problematic because you might have some generic function that uses this T & U -> T principle, but invoke the function with T instantiated with an exact type. So there's no way we could make this sound (it's really not OK to error on instantiation) - not necessarily a blocker, but it's confusing to have a generic function be more permissive than a manually-instantiated version of itself!

It's also assumed that T is always assignable to T | U, but it's not obvious how to apply this rule if U is an exact type. Is { s: "hello", n: 3 } assignable to { s: string } | Exact<{ n: number }>? "Yes" seems like the wrong answer because whoever looks for n and finds it won't be happy to see s, but "No" also seems wrong because we've violated the basic T -> T | U rule.

Miscellany

What is the meaning of function f<T extends Exact<{ n: number }>(p: T) ? 😕

Often exact types are desired where what you really want is an "auto-disjointed" union. In other words, you might have an API that can accept { type: "name", firstName: "bob", lastName: "bobson" } or { type: "age", years: 32 } but don't want to accept { type: "age", years: 32, firstName: 'bob" } because something unpredictable will happen. The "right" type is arguably { type: "name", firstName: string, lastName: string, age: undefined } | { type: "age", years: number, firstName: undefined, lastName: undefined } but good golly that is annoying to type out. We could potentially think about sugar for creating types like this.

Summary: Use Cases Needed

Our hopeful diagnosis is that this is, outside of the relatively few truly-closed APIs, an XY Problem solution. Wherever possible we should use EPC to detect "bad" properties. So if you have a problem and you think exact types are the right solution, please describe the original problem here so we can compose a catalog of patterns and see if there are other solutions which would be less invasive/confusing.

[lazytype]

A tweet from @sebmarkbage (React core contributor)

It turned out to be really helpful for RSC that passing extra props is an error in Flow by default:

https://flow.org/try/#1N4Igxg9gdgZglgcxALlAJwKYEMwBcD6aArlLnALYYrgA2WAzvXGCADQgYAeOBARgJ74AJhhhYiNXClzEM7DFCLl602QF92kEdQD0AKgAEAARg0IAdwN6dAHSh2YJPHGgGYECAAoADmgjf6ZANgTiDFcl4MNDUASmC7NTsHJzJXXiw0Hz8AoJCwpUi0VgN+IPoZOCgEWPioAwNMXCI0OvcvX396GIBuBKSodMy8gwBGYtKDAHI2ydjeqDYQADcopmhqJYAGADoAJk2ANm3NkDUgA

vs TypeScript:

https://www.typescriptlang.org/play?ssl=1&ssc=1&pln=3&pc=1#code/GYVwdgxgLglg9mABMOcAUAHATnDBnALkQG8APIsEAWwCMBTLAXwEoSAoRtt0SWBRGgEMsmHPiJkK1elgA0iAJ5E8ULDDABzFu0SIsdKCCxIU6bLjzMA3By5CRkxAEZ5SxAHJT7lja5sgA

It was addressed to solve unsoundness when spreading. It also helps avoid passing unwanted fields to the client.

[Peeja]

@lazytype FYI, that TS Playground link is broken. It's news to me, but apparently without the www subdomain it goes to the front page instead of the Playground. 🙈 Here's the proper link.

[TylerR909]

Adding my use-case: TypeScript should be lighting up foo: "bar" as invalid on the last line, but it's not, despite MakeFilter and Filter being specific about what this inner function should return:

type Filter = { id: string }
type MakeFilter = () => Filter
function create() {
  return (fn: MakeFilter) => () => {};
}

const make = create()
// const make: (fn: MakeFilter) => () => void
const voidFn = make(() => ({ id: "asdf", foo: "bar" }))

Moot, but voidFn eventually gets passed to an onClick: VoidFunction to execute the () => {} portion of create() which has now been primed.

[dead-claudia]

@TylerR909 That would be an excess property checking bug. Exact types wouldn't (and shouldn't) fix that.

You'd be better off filing a new issue with that.

[loynoir]

@RyanCavanaugh

Label Awaiting More Feedback was added in 2017.

Any news, or comments, in 2023?

[edelbalso]

I want to add my use case here, it deals with leaning on the TS type checker for safely transforming complex data types.

I'll illustrate the bug I had with a simpler example of the type of transformation that's tricky:

type Type1 = {
  A: string
  B: string
}

type Type2 = {
  a: number
  b: number
}

const transform = (obj: Type1): Type2 => {
  const renamed = renameKeys(obj)
  const transformed = convertValues(renamed)
  return transformed
}

const renameKeys = (obj:Type1) => {
  return {
    a: obj.A,
    B: obj.B,
  }
}

const convertValues = (obj: ReturnType<typeof renameKeys>) => {
  return {
    ...obj,
    a: parseInt(obj.a,10),
    b: parseInt(obj.B,10),
  }
}

console.log(transform({ A: '1', B: '2'}))

The transform function has a simple input type and return type, and this code has no type errors but prints, surprisingly:

{
  "a": 1,
  "B": "2",
  "b": 2
}

As you can see, I accidentally mis-typed the B key in the renameKeys function, and I was expecting that the type checker would catch that this through the inference chain and the fact that transform has return type of Type2, but the lack of an ability to opt-in to matching types exactly prevents me from catching this type of bug with the type checker, and it's been SUPER painful since we do a lot of these transformations in our code.

The only way to prevent this is to remember to do a stricter runtime check with something like zod which actually allows me to opt-in to exact checking with the strict() function, so I've had to refactor the code to look like this due to the missing feature in TS:

type Type1 = {
  A: string
  B: string
}

const Type2Schema = z.object({
  a: z.number(),
  b: z.number(),
}).strict()

type Type2 = z.infer<typeof Type2Schema>

const transform = (obj: Type1): Type2 => {
  const renamed = renameKeys(obj)
  const transformed = convertValues(renamed)
  return Type2Schema.parse(transformed)
}

const renameKeys = (obj:Type1) => {
  return {
    a: obj.A,
    B: obj.B,
  }
}

const convertValues = (obj: ReturnType<typeof renameKeys>) => {
  return {
    ...obj,
    a: parseInt(obj.a,10),
    b: parseInt(obj.B,10),
  }
}

console.log(transform({ A: '1', B: '2'})) // <-- now throws an ZodError due to existence of `B` key.

It works, but hard to remember exactly when I need to deploy this pattern. I know I could deploy intermediary types here in the transform flow, but that's something that's really cumbersome when the data gets complex and we want to decompose our transformations.

I also don't think EPC can help me here, unless I'm missing something.

[pc-erin]

@edelbalso

The way I've managed tracking which objects have been validated as exact is to just tag them.

type Exact<T> = T & {readonly _exact: unique symbol }

function toExact<T extends {}>(obj: T, allowedKeys: (keyof T)[]): Exact<T> {
	const r = {} as Exact<T>

	allowedKeys.forEach(key => {
		(r[key] as any) = obj[key]
	})

	return r
}

Then a function can just take a parameter of type Exact<WrappedType> instead of WrappedType.