Negated types #29317

weswigham · 2019-01-09T01:46:24Z

Long have we spoken of them in hushed tones and referenced them in related issues, here they are:

Negated Types

Negated types, as the name may imply, are the negation of another type. Conceptually, this means that if string covers all values which are strings at runtime, a "not string" covers all values which are... not. We had hoped that conditional types would by and large subsume any use negated types would have... and they mostly do, except in many cases we need to apply the constraint implied by the conditional's check to it's result. In the true branch, we can just intersect the extends clause type, however in the false branch we've thus far been discarding the information. This means unions may not be filtered as they should (especially when conditionals nest) and information can be lost. So that ended up being the primary driver for this primitive - it's taking what a conditional type false branch implies, and allowing it to stand alone as a type.

Syntax

not T

where T is another type. I'm open to bikeshedding this, or even shipping without syntax available, but among alternatives (!, ~) not reads pretty well.

Identities

These are little tricks we do on negated type construction to help speed things along (and give negations on algebraic types canonical forms).

not not T is T
not (A | B | C | ...) is not A & not B & not C & not ...
not (A & B & C & ...) is not A | not B | not C | not ...
not unknown is never
not never is unknown
not any is any (since any is the NaN of types and behaves as both the bottom and top)

Assignability Rules

Negated types, for perhaps obvious reasons, cannot be related structurally - the only sane way to relate them is in a higher-order fashion. Thus, the rules governing these relations are very important.

A negated type not S is related to a negated type not T if T is related to S.
This follows from the set membership inversion that a negation implies - if normally a type S and a type T would be related if S is a subset of T, when we take the complements of those sets, not S and not T, those sets share an inverse relationship to the originals.
A type S is related to a negated type not T if the intersection of S and T is empty
We want to check if for all values in S, none of those values are also in T (since if they are, S is not in the negation of T). The intersection of S and T, when simplified and evaluated, is exactly the description of the common domain of the two. If this domain is empty (never), then we can conclude that there is no overlap between the two and that S must lie within not T.
A negated type not S is not related to a type T.
A negated type describes a set of values that reaches from unknown to its bound, while a normal type describes values from its bound to never - it's impossible for a negated type to satisfy a normal type

Assignability Addendum for Fresh Object Types

Frequently we want to consider a fresh object type as a singleton type (indeed, some examples in the refs assume this) - it corresponds to one runtime value, not the bounds on a value (meaning, as a type, both its upper and lower bounds are itself). Using this, we can add one more rule that allows fresh literal types to easily satisfy negated object types.

A fresh object type S is related to a negated type not T if S is not related to T.
Since S is a singleton type, we can assume that so long as it's type is not in T, then it is in not T.

Examples

Examples of negated type usage can be found in the tests of this PR (there's a few hundred lines of them, and probably some more to come for good measure), but here's some of the common ones, pulled from the referenced issues:

declare function ignore<T extends not (object & Promise<any>)>(value: T): void;
declare function readFileAsync(): Promise<string>;
declare function readFileSync(): string;
ignore(readFileSync());     // OK
ignore(readFileAsync());    // Should error

declare function map<T, U extends not void>(values: T[], map: (value: T) => U) : U[]; // validate map callback doesn't return void

function foo() {}

map([1, 2, 3], n => n + 1); // OK
map([1, 2, 3], foo);        // Should error

function asValid<T extends not null>(value: T, isValid: (value: T) => boolean) : T | null {
    return isValid(value) ? value : null;
}

declare const x: number;
declare const y: number | null;
asValid(x, n => n >= 0);    // OK
asValid(y, n => n >= 0);    // Should error

function tryAt<T extends not undefined>(values: T[], index: number): T | undefined {
    return values[index];
}

declare const a: number[];
declare const b: (number | undefined)[];
tryAt(a, 0);    // OK
tryAt(b, 0);    // Should error

Fixes #26240.
Allows #27711 to be cleanly fixed with a lib change (example in the tests).

Ref #4183, #4196, #7648, #12215, #18280

DanielRosenwasser · 2019-01-09T21:18:37Z

tests/baselines/reference/keyofAndIndexedAccessErrors.errors.txt

@@ -46,7 +46,6 @@ tests/cases/conformance/types/keyof/keyofAndIndexedAccessErrors.ts(87,5): error
 tests/cases/conformance/types/keyof/keyofAndIndexedAccessErrors.ts(103,9): error TS2322: Type 'Extract<keyof T, string>' is not assignable to type 'K'.
  Type 'string & keyof T' is not assignable to type 'K'.
    Type 'string' is not assignable to type 'K'.
-      Type 'string' is not assignable to type 'K'.


I'm not complaining, but why'd this go away?

I accidentally fixed a bug where we duplicated the elaboration - this is as the same as the line above.

DanielRosenwasser · 2019-01-09T21:19:20Z

First take, without having tried this out:

Intersections appear to be the correct mechanism to check for potential overlap, but that also means almost no object type can satisfy a negated object type. If we add negated types, I would prefer not to give the check up at all though.
I find it weird, but understandable, that you treat fresh object types differently. But it's clearly weird that these are the only exception to the above issue.

I do have some reservations on the feature for these reasons. If you think about our features trying to satisfy convenience, intent, and safety, then I don't know if this appropriately weighs convenience and intent.

weswigham · 2019-01-09T21:42:06Z

Intersections appear to be the correct mechanism to check for potential overlap, but that also means almost no object type can satisfy a negated object type. If we add negated types, I would prefer not to give the check up at all though.

not (object & SomeInterface)

It works just dandy~

DanielRosenwasser · 2019-01-09T21:54:43Z

It works just dandy~

What do you mean? Yesterday you mentioned that you couldn't assign an array to a not PromiseLike<any>.

weswigham · 2019-01-09T21:59:11Z

Nope, you can't, because you can trivially make a

interface PromiseLikeArray extends Array<any> implements PromiseLike<any> { /*...*/ }

so, if you go to the example, I just state that I explicitly return an array that isn't PromiseLike - that is T[] & not PromiseLike<any>

weswigham · 2019-01-09T22:21:59Z

Per offline feedback from @ahejlsberg I've changed from ~ unary operator to a not keyword type operator (and updated all the text in this PR thus far to match). It does read nicer.

Jessidhia · 2019-01-10T05:17:40Z

Can this be used as a way to restrict the potential type of unbounded types? For example, number & not 0 to allow any number except the literal 0.

This doesn't look very useful at first glance but it can be powerful on mapped types. For example, [key in string and not keyof CSS.Properties<any>] in https://github.com/DefinitelyTyped/DefinitelyTyped/blob/e836acc75a78cf0655b5dfdbe81d69fdd4d8a252/types/styled-components/index.d.ts#L16-L25 could allow the constrained index signature to not have to include CSS.Properties<string | number>[keyof CSS.Properties<string | number>].

weswigham · 2019-01-10T06:41:03Z

Can this be used as a way to restrict the potential type of unbounded types? For example, number & not 0 to allow any number except the literal 0.

Yep. That's a primary driver for 'em.

Jessidhia · 2019-01-10T10:11:53Z

type Exact<T extends object> = T & Partial<Record<not keyof T, never>>

🤔

jack-williams · 2019-01-10T11:01:45Z

Is there an outline of how not interacts with narrowing? Might we have something like?

function foo(x: unknown) {
  if (typeof x === "number") {
    const num: number = x;
  } else {
    const numNot: not number = x;
  }
}

Assignability Addendum for Fresh Object Types

Is there a short example that demonstrates wanting a not for an object literal?

@DanielRosenwasser Do you mean something like { x: number } is not assignable to not { x: boolean } because { x : number} & { x: boolean } does not get reduced to never.

Meta question for @DanielRosenwasser: You say:

convenience, intent, and safety

that seem like some internal principles the TS team have for designing features? Is there a public description of these? I think it would help feature proposals if external contributors could frame their suggestions with the same language used internally.

@Kovensky I'm not sure that will type-check. The type not keyof T includes any type which isn't one of the keys, such as boolean. You might need:

type Exact<T extends object> = T & Partial<Record<(not keyof T) & string, never>>

though I'm not sure what the semantics will be for not types appearing in mapped type constraints.

weswigham · 2019-01-10T18:07:49Z

Is there an outline of how not interacts with narrowing? Might we have something like?

In this PR no negated types are produced by control flow yet; however we've talked over it and negated types make the lib type facts PR elegant to implement, since we can skip using conditionals (which don't compose well) and just filter with intersections of negated types :D

Is there a short example that demonstrates wanting a not for an object literal?

Aye, a test case with an example I pulled from a related issue:

// from https://github.com/Microsoft/TypeScript/issues/4183
type Distinct<A, B> = (A | B) & not (A & B);
declare var o1: {x};
declare var o2: {y};

 declare function f1(x: Distinct<typeof o1, typeof o2>): void;

 f1({x: 0});         // OK
f1({y: 0});         // OK
f1({x: 0, y: 0});   // Should error

though I'm not sure what the semantics will be for not types appearing in mapped type constraints.

Right now they're quietly dropped (aside from filtering out mismatching concrete types), like symbol for the same reason. There's no non-generic concept to map them into. I have a test to that effect. The arbitrary index signatures PR fixes this and would allow an index signature of a, say, string & not "". With that in place mapped types work correctly with 'em, since the intersections trivially desugar to an index signature.

jack-williams · 2019-01-10T18:38:45Z

@weswigham Thanks! And this PR is very cool :)

Re: the object literal example. Should that not be a case where EPC raises an error? I know it doesn't right now because there is no discriminant, but it probably should. Will using negation types become the canonical way of dealing with examples like this? If not, and assuming EPC does get fixed, are there many other use-cases for the special object literal relation.

weswigham · 2019-01-10T21:18:06Z

Re: the object literal example. Should that not be a case where EPC raises an error? I know it doesn't right now because there is no discriminant, but it probably should. Will using negation types become the canonical way of dealing with examples like this? If not, and assuming EPC does get fixed, are there many other use-cases for the special object literal relation.

Even if excess property checking makes defining a type like Distinct unneeded, you'd still need the relationship to allow a type like Distinct to be satisfiable (with fresh object types) should one be used.

SalathielGenese · 2019-01-15T01:24:57Z

Good job so far, I delayed some projects to wait for this feature - for more than a year.

jack-williams · 2019-01-16T09:56:54Z

Do these identities hold?
T & (not T) is never.
T & (not U) is T when T and U are disjoint.
"2b" | (not "2b") is unknown, or generally T | (not T) is unknown.

Just wondering what it would take to fix #28131

weswigham · 2019-01-16T17:51:42Z

T & (not T) is never.

Yes. More generally, when U extends T, U & not T is never.

T & (not U) is T when T and U are disjoint.

Yes.

"2b" | (not "2b") is unknown, or generally T | (not T) is unknown

More generally when U extends T, T | not U is just unknown (quite literally the opposite of the intersection into never rule). That's correct though I don't remember if I'd actually implemented this one yet - afaik we don't currently have any union identities that cause unions to "simplify" to unknown yet so I remember thinking about how it's best accomplished for a bit.

DanielRosenwasser · 2019-01-23T04:31:42Z

src/compiler/checker.ts

+                        const result = isRelatedTo(source, (target as NegatedType).type);
+                        return result === Ternary.Maybe ? Ternary.Maybe : result ? Ternary.False : Ternary.True;
+                    }
+                    // Relationship check is S ⊂ T


Do you really need to use this symbol? It almost sounds like a joke, but this could affect memory footprint when bootstrapping the compiler since modern engines can avoid full UTF16 representations https://blog.mozilla.org/javascript/2014/07/21/slimmer-and-faster-javascript-strings-in-firefox/

A minification step will simply remove this line. The article suggests to minify the code to utilise the inline strings and also help with strings interning. I guess, v8 should not be so much different in this sense and also win from code minification.

jack-williams · 2019-01-24T22:30:50Z

@weswigham Seems to work, right?

type UnionToInterWorker<T> = not (T extends T ? not T : never);
type UnionToInter<T> = [T] extends [never] ? never : UnionToInterWorker<T>;

Not quite sure what should happen here:

type NotInfer<T> = T extends not (infer U) ? U : never;
type NotString = NotInfer<string> // string extends not U ? U : never;

Currently it doesn't reduce; maybe infer types should be disallowed under not?

weswigham · 2019-01-24T22:43:47Z

It doesn't reduce because we don't reduce reducible conditionals with infer's in them right now. IMO, it certainly still makes sense to allow an infer inside a not, since not A extends not infer B ofc should infer A for B.

jack-williams · 2019-01-24T22:54:41Z

Yep, you're right. I guess it could infer U = not string?

yuhr · 2021-07-14T08:33:22Z

By the way, for those who want to use negated types in function parameters, you can already (at least in v4.3.5) mimic it by using conditional types for the parameter's type:

function f<T>(x: T extends string ? never : T) { return x }

f(42)
f("42") // Argument of type 'string' is not assignable to parameter of type 'never'.(2345)

TS Playground

awerlogus · 2021-07-14T13:25:57Z

@yuhr

By the way, for those who want to use negated types in function parameters, you can already (at least in v4.3.5) mimic it by using conditional types for the parameter's type:
function f<T>(x: T extends string ? never : T) { return x }

f(42)
f("42") // Argument of type 'string' is not assignable to parameter of type 'never'.(2345)

You can also use pseudo enums to get readable error messages:

declare enum non_string { non_string = '' }

function f<T>(x: T extends string ? non_string : T) { return x }

f(42)
f("42") // Argument of type '"42"' is not assignable to parameter of type 'non_string'.(2345)

But the approach you have suggested has significant drawbacks. The most serious of them is that you can't combine such functions with others. You can't pass it as an argument to other functions, because the type inference will be broken, you can't apply Parameters and ReturnType types to them e.t.c. It's the flaw of the TypeScript itself, that some parts of the language contradict others. Therefore, there is nothing we can do about it, except to abandon the use of this approach.

SNDST00M · 2021-07-15T19:47:39Z

There's also the inability to use the conditional type without a Anders type parameter (e.g. f<42>(42))

strblr · 2021-07-21T15:54:10Z

Any update on negated types ?

JustFly1984 · 2021-12-18T03:53:42Z

Would love to have type 'string & not ""' and 'number & not 0'

Jamesernator · 2022-03-24T02:23:03Z

This has been something I've really been wanting again today to be able to define a-factory-or-type type that supports lifting into the factory type.

Effectively I'm currently doing the following:

type Create<Ctx, T> = (ctx: Ctx) => T;
type Liftable<Ctx, T> = T | Create<Ctx, T>;

function lift<Ctx, T>(
    liftable: Liftable<Ctx, T>,
): Create<Ctx, T> {
    if (typeof liftable === "function") {
        return liftable;
    }
    return () => liftable;
}

But predictably return liftable is the error:

Type 'Create<Ctx, T> | (T & Function)' is not assignable to type 'Create<Ctx, T>'.
  Type 'T & Function' is not assignable to type 'Create<Ctx, T>'.
    Type 'Function' provides no match for the signature '(ctx: Ctx): T'.(2322)

This obviously happens because typeof liftable === "function" couldn't distinguish if T itself was a function type. So the usual hack is just to do:

return liftable as any;

However for my purposes there's actually no use cases where Liftable<Function> needs to be allowed, it would be far preferable to define everything as:

type Create<Ctx, T extends not Function> = (ctx: Ctx) => T;
type Liftable<Ctx, T extends not Function> = T | Create<Ctx, T>;

function lift<Ctx, T extends not Function>(
    liftable: Liftable<Ctx, T>,
): Create<Ctx, T> {
    if (typeof liftable === "function") {
        return liftable; // Hey this is type safe now
    }
    return () => liftable;
}

wbt · 2022-03-29T19:51:51Z

This is also something I'd like to see, due to an unfiled duplicate of #48373 where it's noted

You can't represent a type "any string except this one" in TypeScript.

Sometimes it would be quite useful to be able to do that; for example when using the 'kind' attribute of a library type (e.g. FileSystemHandle in the DOM) to discriminate between subclasses and wishing to include a general else clause reporting an unrecognized kind in case additional subclasses are added in the future.

qwelias · 2022-05-15T21:50:54Z

Love coming back to this PR about once or twice a year because of not being able to do something.
Is there a chance to get any update on the state of it?

weswigham requested review from sandersn, DanielRosenwasser, rbuckton and ahejlsberg Jan 9, 2019

DanielRosenwasser reviewed Jan 9, 2019

View changes

weswigham closed this Jan 9, 2019

weswigham reopened this Jan 9, 2019

weswigham mentioned this pull request Jan 16, 2019

Exact Types #12936

Open

DanielRosenwasser reviewed Jan 23, 2019

View changes

RyanCavanaugh added this to This Week in Design Meeting Docket Jan 23, 2019

RyanCavanaugh assigned weswigham Jan 24, 2019

jack-williams mentioned this pull request Jan 24, 2019

Provisional - Add not keyword emacs-typescript/typescript.el#98

Closed

bergundy mentioned this pull request Jul 6, 2021

[Bug] Query handler should not be async temporalio/sdk-typescript#148

Closed

nikeee mentioned this pull request Jul 11, 2021

Proposal: Interval Types / Inequality Types #43505

Open

5 tasks

MartinJohns mentioned this pull request Aug 2, 2021

Infinite unions #45275

Closed

5 tasks

simonlovesyou mentioned this pull request Aug 4, 2021

Add key duplication safety simonlovesyou/cling#25

Open

dead-claudia mentioned this pull request Aug 14, 2021

Existential type? #14466

Open

treybrisbane mentioned this pull request Aug 26, 2021

Track non-null unknown types in control flow analysis #45575

Merged

dead-claudia mentioned this pull request Sep 5, 2021

Mithril: correct generic Element type to HTMLElement DefinitelyTyped/DefinitelyTyped#55550

Closed

8 tasks

jcalz mentioned this pull request Sep 15, 2021

Make type predicates combinable with other types #45890

Closed

5 tasks

fatcerberus mentioned this pull request Oct 6, 2021

Conditional parameter type based on generic type has inconsistent behavior when generic type passed as generic argument #46155

Closed

MartinJohns mentioned this pull request Oct 21, 2021

Strict optional properties #43947

Merged

frandiox mentioned this pull request Nov 17, 2021

fix: warn and ignore reserved properties in server state Shopify/hydrogen#241

Merged

4 tasks

gooin mentioned this pull request Nov 19, 2021

3 - 实现 Omit type-challenges/type-challenges#4558

Open

fatcerberus mentioned this pull request Dec 18, 2021

Exclude<string, SomeType> not working as expected #47178

Closed

MartinJohns mentioned this pull request Dec 20, 2021

Extract<string, 'a'> != 'a' #47201

Closed

jcalz mentioned this pull request Jan 24, 2022

ReadonlyArray.some does not perform type narrowing #47574

Open

tychenjiajun mentioned this pull request Feb 11, 2022

Proposal: Add not sindresorhus/ts-extras#32

Open

MartinJohns mentioned this pull request Mar 1, 2022

Make it possible to have partially discriminated unions #48073

Closed

5 tasks

RyanCavanaugh mentioned this pull request Mar 22, 2022

Discriminated union doesn't work when using strings and Exclude or string extends 'xyz' ? 'xyz' : never #48373

Closed

This comment has been hidden.

Sign in to view

whzx5byb mentioned this pull request Apr 7, 2022

Anonymous type parameters #48594

Open

jiangshanmeta mentioned this pull request May 10, 2022

TypeScript中为primitive type添加名义类型 jiangshanmeta/jiangshanmeta.github.io#45

Open

MartinJohns mentioned this pull request May 15, 2022

Typeguard not working if checked against Exclude #49118

Closed

microsoft / TypeScript Public

Negated types #29317

Negated types #29317

weswigham commented Jan 9, 2019 •

edited

DanielRosenwasser Jan 9, 2019

weswigham Jan 9, 2019

DanielRosenwasser commented Jan 9, 2019

weswigham commented Jan 9, 2019 •

edited

DanielRosenwasser commented Jan 9, 2019 •

edited by weswigham

weswigham commented Jan 9, 2019 •

edited

weswigham commented Jan 9, 2019 •

edited

Jessidhia commented Jan 10, 2019

weswigham commented Jan 10, 2019

Jessidhia commented Jan 10, 2019

jack-williams commented Jan 10, 2019 •

edited

weswigham commented Jan 10, 2019 •

edited

jack-williams commented Jan 10, 2019

weswigham commented Jan 10, 2019 •

edited

SalathielGenese commented Jan 15, 2019 •

edited

jack-williams commented Jan 16, 2019

weswigham commented Jan 16, 2019

DanielRosenwasser Jan 23, 2019

peter-leonov Jan 23, 2019

jack-williams commented Jan 24, 2019 •

edited

weswigham commented Jan 24, 2019 •

edited

jack-williams commented Jan 24, 2019

yuhr commented Jul 14, 2021

awerlogus commented Jul 14, 2021

SNDST00M commented Jul 15, 2021

strblr commented Jul 21, 2021

JustFly1984 commented Dec 18, 2021

Jamesernator commented Mar 24, 2022 •

edited

This comment has been hidden.

wbt commented Mar 29, 2022

qwelias commented May 15, 2022

Apr	MAY	Jun
	18
2021	2022	2023

microsoft / TypeScript Public

Negated types #29317

Are you sure you want to change the base?

Negated types #29317

Conversation

weswigham commented Jan 9, 2019 • edited

Negated Types

Syntax

Identities

Assignability Rules

Assignability Addendum for Fresh Object Types

Examples

DanielRosenwasser Jan 9, 2019

Choose a reason for hiding this comment

weswigham Jan 9, 2019

Choose a reason for hiding this comment

DanielRosenwasser commented Jan 9, 2019

weswigham commented Jan 9, 2019 • edited

DanielRosenwasser commented Jan 9, 2019 • edited by weswigham

weswigham commented Jan 9, 2019 • edited

weswigham commented Jan 9, 2019 • edited

Jessidhia commented Jan 10, 2019

weswigham commented Jan 10, 2019

Jessidhia commented Jan 10, 2019

jack-williams commented Jan 10, 2019 • edited

weswigham commented Jan 10, 2019 • edited

jack-williams commented Jan 10, 2019

weswigham commented Jan 10, 2019 • edited

SalathielGenese commented Jan 15, 2019 • edited

jack-williams commented Jan 16, 2019

weswigham commented Jan 16, 2019

DanielRosenwasser Jan 23, 2019

Choose a reason for hiding this comment

peter-leonov Jan 23, 2019

Choose a reason for hiding this comment

jack-williams commented Jan 24, 2019 • edited

weswigham commented Jan 24, 2019 • edited

jack-williams commented Jan 24, 2019

yuhr commented Jul 14, 2021

awerlogus commented Jul 14, 2021

SNDST00M commented Jul 15, 2021

strblr commented Jul 21, 2021

JustFly1984 commented Dec 18, 2021

Jamesernator commented Mar 24, 2022 • edited

This comment has been hidden.

wbt commented Mar 29, 2022

qwelias commented May 15, 2022

weswigham commented Jan 9, 2019 •

edited

weswigham commented Jan 9, 2019 •

edited

DanielRosenwasser commented Jan 9, 2019 •

edited by weswigham

weswigham commented Jan 9, 2019 •

edited

weswigham commented Jan 9, 2019 •

edited

jack-williams commented Jan 10, 2019 •

edited

weswigham commented Jan 10, 2019 •

edited

weswigham commented Jan 10, 2019 •

edited

SalathielGenese commented Jan 15, 2019 •

edited

jack-williams commented Jan 24, 2019 •

edited

weswigham commented Jan 24, 2019 •

edited

Jamesernator commented Mar 24, 2022 •

edited