Почему TypeScript не упрощает этот тип пересечения?

Общий ответ на вопрос: «Почему TypeScript агрессивно не сокращает пересечения взаимоисключающих типов до никогда?» «это было бы вычислительно невозможно сделать». Может показаться разумным ожидать, что {a: X} & {a: Y} следует уменьшить до never, если X & Y сократится до never. Но это очень плохо масштабируется; если несовместимый тип встречается в каком-то глубоко вложенном месте, то мы попросим компилятор выполнить полную проверку структурного типа для всех типов пересечений, прежде чем продолжить. Некоторые типы являются рекурсивными, поэтому во многих случаях это становится практически невозможным.

Авторитетный ответ см. в этом комментарии к microsoft/TypeScript#57246 руководителя группы разработчиков TS : «Непрактично упрощать все возможные необитаемые типы до never — это требует потенциально неограниченного объема работы. . Поскольку это невозможно, это не инвариант, от которого вы должны пытаться получить зависимость.», или этот твит того же автора , упомянутый в microsoft/TypeScript#50581. Вы можете довольно легко написать тип, который выдает never где-то очень глубоко в объекте, и мы просто не можем ожидать, что TypeScript будет охотиться за ними.

Говоря прагматично, бывают случаи, когда TypeScript намеренно допускает существование таких невозможных пересечений. Канонический — это фирменные примитивы вида string & {prop: number} или number & {xyz: 123}. Очевидно, что эти вещи никогда не будут существовать во время выполнения, но TypeScript делает вид, что они существуют, чтобы позволить вам притвориться, что существует некая различающая структура между идентичными в остальном типами. Агрессивное сокращение количества вещей до never в конечном итоге приведет к нарушению подобных случаев.

Действительно, вы могли бы написать что-то самостоятельно, что действительно существует во время выполнения и хорошо типизировано в соответствии с системой типов, которую TypeScript не сокращает агрессивно:

const x = {
  a: "hello",
  get b(): never { throw new Error("Don't look at this poperty!"); }
}
/* const x: {
    a: number;
    readonly b: never;
} */

Здесь значение x имеет тип, свойство b которого правильно имеет тип never. Но x прекрасно существует, и если вы не пытаетесь прочитать свойство b, вы можете использовать его сколько угодно:

console.info(x.a.toUpperCase()) // "HELLO"

Только если вы зайдете на b, у вас возникнут проблемы:

console.info(x.b) // OH NOEZ

Так нужно ли было x сократить до never? Неясно, какова будет польза от такого сокращения. Конечно, эти странные вещи с never-геттерами могут быть не идиоматическими, поэтому неясно, есть ли огромная польза от предотвращения сокращения, но важно помнить о ситуациях, когда на самом деле могут существовать кажущиеся невозможными типы, поэтому мы будем делать взлом изменения в TypeScript, если мы их реализовали.

Итак, если TypeScript вообще не делает такого сокращения, то почему он это делает, когда конфликтующее свойство представляет собой буквальный тип , подходящий для использования в качестве дискриминантного свойства дискриминируемого объединения?

Что ж, такого поведения на самом деле не было раньше В TypeScript 3.9 было введено сокращение пересечений с помощью дискриминантных свойств , как это реализовано в microsoft/TypeScript#36696.

Это было реализовано как исправление для microsoft/TypeScript#36736 , которое жаловалось на то, что мы не можем использовать пересечения для извлечения членов из дискриминируемых объединений. Сопровождающие языка могли бы сказать «вместо этого используйте Extract<T, U>», но они проверили, что произойдет, если это будет реализовано, и оказалось, что ничего важного не сломалось, поэтому они сохранили его.

Если вы вернетесь к более ранним версиям TypeScript, вы увидите, что даже такие вещи, как "x" & "y", изначально не сводились к never. Сначала их оставили в покое, затем они были сокращены до never при появлении в объединениях , как это реализовано в microsoft/TypeScript#18438 , а затем они в конечном итоге были полностью сокращены до never, как это реализовано в microsoft/TypeScript#. 31838.

Поэтому вполне возможно, что в какой-нибудь будущей версии TypeScript ваш код будет вести себя так, как вы ожидали. Но для того, чтобы это было правдой, необходимо установить, что

• существует потребность сообщества в таком сокращении
• это можно сделать без слишком большого дополнительного времени компиляции (поэтому это должен быть поверхностный анализ)
• это не нарушает реальный код, который каким-то образом зависит от того, не сокращается ли пересечение

Это кажется маловероятным, особенно потому, что ["x"] не так уж широко используется как признак дискриминации, но все возможно!

Детская площадка, ссылка на код