Design Meeting Notes, 2026-08-27

# Negated Types (`not T`)

https://github.com/microsoft/TypeScript/pull/63926

* If you think about a venn diagram of `A` and `B` overlapping where `A & B` is the overlap, `not A` is all the area outside of `A`, `not (A & B)` is the inverse color of that original overlap.
* Fresh object types are closed -
* Talked about this before, have a feeling it's more relevant today.
* Like what?
* Something like a `--noUnusedReturnedValues`
* Don't want to forget
* People use `void`, but this accepts `Promise`s that need to be `await`ed.
* Can have an `ignore` to help here.

```ts
function ignore(value: not PromiseLike): void {}
```
* `` `foo${string & not "reserved-key"}` ``
* `` Record<`on${string & not keyof EventNames}`, unknown> ``
* Can also do narrowing for carve outs of infinite sets.

```ts
function divide(a: number, b: number & not 0): number {
return a / b;
}

function doStuff(someValue: number) {
if (someValue !== 0) {
divide(10, x); // Okay

// (come back to this below)
const x = someValue;
divide(10, x); // ...
}
else {
divide(10, someValue); // Should error!
}
}
```
* Okay, but how does that work with aliases
* Currently an alias loses that information.
* That is super surprising.
* What are the old issues that this avoids?
* We had a prototype that swapped out our fact-tracking system in control flow analysis and replaced it with negated type tracking.
* But this was computationally intensive.
* This PR introduces negations only for specific types of control flow narrowing in the false branch where we needed to track that info.
* Only requests negation when a use-site of a binding needs negation.
* Done based on the contextual type at that use-site.
* We actually have similar logic here for when we narrow generic parameters in the body of a function!
* Very similar precedent here.
* Do you want the most precise type to be inferred
* e.g. type narrowing conditionals (come back to this?)
* We also infer type predicates for you now.
* Negated types seem useful over the set of primitives, and often works well enough in the object hierarchy, but doesn't really make sense to have a provable negated object type.
* An `object` doesn't necessarily exclude a `Promise` or a `Function`.
* But all sorts of checks like this are all heuristics-based.
* Could have a switch to check for negations?
* But is this a strictness thing?
* Feels like no - weird.
* Does this feel consistent?
* Should do this stuff everywhere.
* But if you have a switch case with 200 cases, you'll get 200 `not`s in the default, whether you cared or not. This PR avoids that unless you actually need the negation.
* Let's come back to use-cases.
* `not Promise`
* Control flow issues.
* With this PR, it is very nice that it's both faster and that you don't see the `not`s in hover unless you need.
* We do want to experiment a bit more with decomposing existing primitives here. There are some unknown unknowns here.
* Is `object` equivalent to `{} & not number & not string & not boolean & not symbol`?
* Is `{}` equivalent to `not null & not undefined`?
* Maybe `Extract` and `Exclude` can be defined in this way?
* Or rather, have the compiler produce intersections of negations wherever we otherwise produce these.
* Aside: added a specific mechanism for reducing intersections in the presence of negations.
* What does negation mean in the presence of optional properties?
* `not { optionalProp?: Type }`
* Out of time!

まず会議メモとリンクされている PR #63926 を読み、否定型、制御フローの絞り込み、エイリアス、オプショナルプロパティに重点を置いてください。メモには未解決の設計上の疑問が含まれていますが、ファイル、テスト、エントリポイント、完了条件は挙げられていないため、実装前にさらなる議論とスコープの定義が必要になります。

索引モデルが issue の本文から書いたものです。