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.

[ssalbdivad]

Just want to throw my two cents in that I think of every open issue for a major feature in TS, I believe this one may have the highest ROI. Iterating over keys in TS continues to be one of the largest pain points for a common language feature, and the ability to mitigate that by declaring your type as exact would be a huge help.

I think if it's an opt-in syntax, the semantics around it should be straightforward. A type that could have additional keys is not assignable to a type with the exact constraint.

I think this also implies natural solutions for the issues @RyanCavanaugh raised originally:

it's assumed that a type T & U is always assignable to T, but this fails if T is an exact type

If T is exact and U has required keys not included in T, the result of this intersection should be never. If U's required keys are allowed by T but U is not exact, the result becomes the exact version of T&U, with optional keys unique to U omitted. Neither of these scenarios violates the existing properties of &.

It's also assumed that T is always assignable to T | U

In this situation, the assignment would continue to be allowed. If someone is trying to disambiguate { s: string } | Exact<{ n: number }>, they should not be checking for the presence of n but rather the presence of s.

If you compare the complexity of handling exactness as a type-level constraint to another major feature like negated types, I would estimate it to be at least an order of magnitude less. I would love negated types as well, but I really do think exact types represents a unique opportunity to significantly mitigate one of the most frustrating aspects of TypeScript that fits neatly into the existing type system.

[Tim-Louw]

Is there any update or feedback on whether or not this will be added or worked on?

In the meantime does anyone have a type they have managed to implement which mimics what Exact<> would do?

[Alexandre-Casetta]

You can use this, I haven't tested it extensively but it seems to work well no matter how deep your type is :

type Exact<T, U extends T> = {
    [Key in keyof U]:
        Key extends keyof T
            ? U[Key] extends object
                ? Exact<T[Key], U[Key]>
                : U[Key]
            : never
};

// #1 Example
type Foo = {a: {b: {c: string}[]}};

const bar = <T extends Foo>(baz: Exact<Foo, T>) => {};

const wrong_argument = {a: {b: [{c: '', wrong: ''}]}};
bar(wrong_argument); // Error

const valid_argument = {a: {b: [{c: ''}]}};
bar(valid_argument); // Valid

// #2 Example
type Api = {
    '/users': {
        query: {
            name: string,
        }
    },
    '/articles': {
        query: {
            id: string,
        }
    }
};

const request = <
    Path extends keyof Api,
    Query extends Api[Path]['query'],
    T extends Query,
>(path: Path, query:  Exact<Query, T>) => {};

const wrong_query = {id: '', wrong: ''};
request('/articles', wrong_query);  // Error

const valid_query = {id: ''};
request('/articles', valid_query); // Valid

Typescript Playground:
https://www.typescriptlang.org/play/?#code/C4TwDgpgBAogHgQwMbADwBUA0UCqUJzAQB2AJgM5ToB8UAvFAN4CwAUFB1ANoDSEIUAJbEoAa34B7AGa4AugC42nZVD4CCRMpXEhpVJSsMB+XL36z8hEhSgSARgCsIKA4bdQT8ZGnRmQs7Bw-WWpXdxV5UzVZMPdI4ggANwgAJzYAXwBuNhzWNgB6fKgAYgBGWEQAWzAAGwg2UEgoADEJCXomBEjGO26kSPJgFOEAc3SuWXSs3KQJYkGoOwQUjoxLTRtWiWoACiWAL0ivFFQt7BoASnpaRmm81ln54CgAdxS5kYB9ZZGAV0qSM8GIwukxetxGP0oAByaHYN4fSKw9KTO5LFI7BHEL4-f6Ai6ZKCFWApd5pe6PBaJBA1QSkb4pP4A4hAzrdcFcSFI6EoqbZVjonbU2n03HM4AEolFABqNLpuVyxOKACYKghqnUGuBoABBMCCDosdicaH5X7kVLkaHdWKcACOv1SIBtxvCUGI6ogAyGo0wto46TC6T9rph+WWwEESDqVpd7gdTrjbqEpG9w2xIfcgdD2bubEpzxSEATCwYqDCAAUEMAABbrazaSQyPWCTOcACKjpS6isWigLa4Vdrsi40IT3ehATC6Hrfc7TpDuzA1ZrkSHNew4+dHGOaHn3fO1CudBueYecwWWK+W8NdO58Pe2O5dyLJeAO1NEajMbhr0f167EBJSlEkyRmC9nmFOlPhvYE7xhHl+VfR1Bg-cMUkjaMICtbAoPpLdJWJWURTYIA

Alternatively, if you don't want the Exact type to be deep, you can use this:

type ShallowExact<T, U extends T> = {[Key in keyof U]: Key extends keyof T ? U[Key] : never};

[ssalbdivad]

@Alexandre-Casetta Unfortunately, an approach like this is only possible when validating a function parameter.

For it to work as a standalone type, reason about assignability, allow iterating over narrowed keys etc., it would need to be a first-class language feature.

[kossnocorp]

@Alexandre-Casetta, thank you. That was very helpful in my case!

Edit: it fails with union.

Failing type

const valid_query : { id: string } | { id: string , nope: number } = {id: ''};
request('/articles', valid_query); // Should fail :-(