我认为为已经与现有工具良好配合的事物引入更多关键字和额外语法并不值得。

我认为为已经与现有工具良好配合的东西引入更多关键词和额外语法并不值得。
然而它并不奏效... 难以编写，难以阅读，容易出错，同时又是相当基础的东西，项目会不断重复。

我基本上已经切换到使用 unknown 和 never 代替 true 和 false 进行这种操作。它还有一个额外的好处，就是让你可以使用 & 作为 "and",使用 | 作为 "or"。如果 not 被引入，你可以使用它；目前你需要一个通用的类型别名，如 type Not<T> = [T] extends [never] ? unknown : never 或可能 type Not<T> = unknown extends T ? never : unknown(取决于你想看到 Not<123> 发生什么)。
在那之后，唯一缺少的就是缩写的条件类型语法 C ? Y : N,它代表的是类似于 [C] extends [never] ? N : Y 或可能 unknown extends C ? Y : N(取决于你想看到 123 ? Y : N 发生什么)的东西。我不指望它能被纳入语言中，所以我想在那里你能做的最好的事情就是使用一个通用的类型别名：type Cond<C, Y=unknown, N=never> = [C] extends [never] ? N : Y。

@jcalz could you illustrate your ideas by applying them to the examples above? For instance, to IsIndexSignature , perhaps explaining it a bit? It is quite tricky to become certain that | will equate to a logical or by somehow using never and unknown .
I am curious, because I want to have such a feature today if this is possible, but it is most definitely a hack that I don't wish anybody to be forced to use for what would have otherwise been a very easy task.

我认为“hack”是见仁见智的，在这里。虽然布尔字面量类型 true 和 false 有富有表现力的名字，但它们只表示在运行时存在的布尔 表达式 类型，它们并不像布尔 在类型级别 上的行为。
另一方面，unknown 和 never 是 TypeScript 对 top 和 bottom 类型的名称，它们在类型级别上的行为更像布尔值，这就是你所要求的。
这种对应关系来自于将一个类型等同于可以分配给该类型的某个值的语句：
| 命题逻辑 | 类型系统 | 对应关系 |
| ------------ | ------------ | ------------ |
| T/true/⊤ | unknown (顶层) | 可以分配给 unknown? true。 |
| F/false/⊥ | never (底层) | 可以分配给 never? false。 |
| and/∧ | & (交集) | 可以分配给 A & B 当且仅当它可以分配给 AandB 。 |
| or/∨ | | (并集) | 可以分配给 A | B 当且仅当它可以分配给 either AorB 。 |
| not/¬ | not *(补集) | 可以分配给 not A 当且仅当它不是 not to A 。 |

• 嗯，如果我们得到 negated types

希望这看起来不那么随意了。当然，目前还没有 not ,而且命题逻辑通常没有三元运算符的基本符号，所以我们需要我们自己的 Not<T> 和 Cond<T,Y,N> ,正如我之前所说：
那么，让我们看看你的示例：

type Primitive = boolean | number | string | symbol | null | undefined | void
type IsA<T, E> = T extends E ? unknown : never;
type Cond<C, Y=unknown, N=never> = [C] extends [never] ? N : Y
type IsIndexSignature<P> = IsA<string, P> | IsA<number, P>
type Yes = IsIndexSignature<number> // (never | unknown) = unknown
type No = IsIndexSignature<boolean> // (never | never) = never

这样是否更有意义？

嗯...有点。我尝试用更大的例子替换 true 的几乎每一个出现，用 unknown 替换 false ,用 never 替换 Or<T> ,用 | 替换等等，但我失败了。问题是，以前 IsIndexSignature<T> 可以通过 extends true ? 轻松地用于更大的类型测试。现在这种灵活性丧失了，我认为被迫使用 extends never ? (或 extends [never] ??我真的不明白为什么要用数组 Package ...),因为一切都扩展自 unknown ,因此反转所有条件(相当多)。
底线是，我不认为你的建议是一个合理的建议。黑客并不完全取决于观察者的看法，我想说。这种技巧的安排比“常规二进制逻辑”更难理解--在我看来，痛苦太高，犯错更容易。

我不太明白为什么要用数组 Package ...
如果你指的是这个模式：[T] extends [U] ? Y : N - 它是为了关闭union distribution(参见分布式条件类型)。泛型条件类型Map到联合的各个成员，所以如果我们不希望这种情况发生，我们将类型的联合变成一个“联合元组”，将其视为一个原子类型。你可以替换[T],它几乎可以替代任何其他协变泛型，如Promise<T>,效果是一样的。

这是一段关于TypeScript Handbook中条件类型的描述：

条件类型根据一个表示为类型关系测试的条件选择两种可能的类型之一：

T extends U ? X : Y

上面的类型意味着当T可以分配给U时，类型是X,否则类型是Y。
(来自https://www.typescriptlang.org/docs/handbook/advanced-types.html#conditional-types)
它从未说过条件类型会解析为 true 或 false ,所以如果我们想明确条件的结果，任何二进制值都可以工作， unknown 和 never 肯定是可以的。

但是 true / false 就不行了。
每个人都知道在运行时，true 的相反是 false ,反之亦然(当然除了NaN)。
但在否定类型中，not true 的意思是“任何不能分配给 true 的东西”，而 not false 的意思是“任何不能分配给 false 的东西”。
所以例如 string 同时是 not true 和 not false,那么 string ? true: false 将解析为什么？
然而我不得不承认，使用 unknown 和 never 的方式要少直观得多。
最初我来这里是因为我发现了一个非常酷的 blog post (中文),它仅使用类型系统构建脚本解析器。

(Playground链接)
为了链接多个表达式，作者必须大量使用条件类型。所以我在想是否有任何提案将逻辑运算符添加到条件类型中，就像我们在JavaScript中可以使用 && 一样。