<p>План итерации TypeScript 4.0</p>

Не могли бы вы включить https://github.com/microsoft/TypeScript/pull/29818 в 4.0, возможно, за экспериментальным флагом?

Это усложняется изменением самого определения фабричной функции.

Однако было бы интересно ввести определение виртуального типа фабрики _separate_; скажем, JSX.Factory или React.JSX.Factory , которые TypeScript затем может использовать для логического вывода. Я не совсем уверен, что простого перевода грамматики JSX в вызовы функций достаточно или эффективно, но, поскольку это виртуальный тип, он не должен соответствовать какой-либо конкретной сущности JavaScript. Риск, конечно, заключается в том, чтобы попасть в ту же ситуацию, что и сейчас, с кучей виртуальных типов, которые в итоге ограничили типобезопасность не только дочерних элементов, но и некоторых фич, появившихся после React 15.

Не могли бы вы также включить https://github.com/microsoft/TypeScript/pull/24738 в 4.0?

Мне немного грустно не видеть упоминания о № 33038 [👍 140 и фактический PR от вашего собственного @weswigham] или № 202 [👍 390], в то время как билеты, такие как № 15230 [👍 27], считаются «высоким спросом». Я понимаю, что вы не можете на самом деле сравнивать или расставлять приоритеты на основе «лайков», но было бы здорово, если бы для них было какое-то обновление дорожной карты, тем более что 4.0 кажется хорошей возможностью представить подобную функцию. 🙏

О проблеме 3,5-летней давности, ожидающей отзыва, с почти 200 комментариями #13778 с неточной типизацией для таких вещей, как деструктуризация массива. Pwetty pwease, мы можем реализовать исправление 🙏

Я ценю, что люди время от времени поднимают проблемы, которые, по их мнению, требуют внимания в дорожных картах и ​​планах итераций, но я думаю, что здесь нужно внести ясность: раздел «Исследование исправлений ошибок с высоким спросом» был определен путем просмотра проблем, которые явно вызывали много проблем. papercuts, но которые казались разумными по объему. Мы определенно по-прежнему помним об упомянутых проблемах, но некоторые из них не имеют такого масштаба и не имеют четкого идеального результата.

Примеры:

• Номинальные бренды были бы хороши, но будет ли это сочетаться с будущим языковым направлением вокруг номинальности? У меня даже есть эта проблема с типами заполнителей как у человека, который это предложил.
• undefined в сигнатурах индексов — пример чего-то интересного, но мы не хотим добавлять поведение, усложняющее работу 90 % людей, которые уже работают с текущими предположениями. Поиск подхода, который объединяет и позволяет пользователям постепенно внедрять эти проверки, не является чем-то очевидным для нас. Даже если это технически возможно с кучей условных типов и специальных проверок компилятора, эти решения, как правило, очень явно хакерские и быстро ломаются.

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

@DanielRosenwasser , каким ты видишь будущее языковое направление?

Думаю, я дам некоторый контекст того, что я думаю о номинальности. Есть много разных идей, которые люди имеют в виду, когда спрашивают о номинальных типах, в том числе

• «Традиционная» номинализация на основе объявлений (например, то, что вы видите в большинстве языков OO)
• Непрозрачные типы (типы, содержимое которых полностью неизвестно снаружи)
• Отдельные псевдонимы (одночленные struct в C/C++/C#, newtype в Haskell, встроенные классы в Kotlin)
• Единицы измерения (способ кодирования размерного анализа в язык)

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

У @RyanCavanaugh была отличная аналогия, когда трое детей просят своих родителей о домашнем животном. Кто-то хочет собаку, кто-то хочет кошку, кто-то хочет рыбу. Они спрашивают своих родителей: «Когда у нас будет питомец!?» Ясно, что все они согласны, что хотят домашнее животное, но каждый хочет другого питомца!

Нравятся ли мне фирменные типы? Я делаю! Фирменные типы достигают чего-то вроде различных псевдонимов и отвечают всем требованиям, которые ищут большинство пользователей. Но я не думаю, что это правильный способ думать об этом. Есть больше пространства для дизайна, которое нужно конкретизировать с большим количеством известных компромиссов, и ничто не дает мне понять, что нам нужно спешить с решением как можно скорее.

Я хотел бы, чтобы мы могли получить https://github.com/microsoft/TSJS-lib-generator/pull/858 в TypeScript 4.0 .

@DanielRosenwasser, прежде всего, спасибо за рецензию 🙇

Не могли бы вы немного рассказать о том, к каким случаям использования номинальных типов относятся TypeScript?

Во-первых: не стесняйтесь посылать меня на гигантскую стену текста или репозиторий, и я прочитаю это :]

Я не имею в виду непрозрачные типы, такие как типы-заполнители, я имею в виду то, что вы называете «традиционными» номинальными типами.

Я всегда чувствовал, что номинальные типы несовместимы с JavaScript, и поэтому предыдущие попытки не работали так хорошо. Есть способы заставить его работать довольно хорошо (протоколы в swift и классы типов в haskell приходят на ум как «номинальные, но расширяемые извне»), и я уверен, что вы знакомы с большинством «хорошо зарекомендовавших себя» способов (я предположим, что «единицы измерения» — это подмигивание F#).

Я нашел много людей, которые просили именные (как в «традиционных») типы, но не так много статей о _почему_.

Со временем мы видим, что все меньше и меньше людей запрашивают «традиционные» номинальные типы, возможно, потому, что коллективно сообщество создало ментальный модус для структурных типов. Есть места, где типы действительно действуют номинально (когда задействованы instanceof или когда есть приваты). Некоторые из них фиксируются улучшенным анализом потока управления и проверками совместимости, но они не идеальны.

Некоторые из «традиционных» вариантов использования такие же, как у номинального типа оболочки с нулевыми накладными расходами (например, newtype ), и в большинстве случаев целью является обеспечение специальной обработки для таких вещей, как файл пути, ненадежные строки и т. д.

Мне кажется, что Typescript уже достаточно выразителен. Что лично я хотел бы видеть, так это лучшую интеграцию инструментов.

• поддержка ESM https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• плагины компилятора https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• пряжа pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

Из-за вышеизложенного часто можно увидеть неуклюжие и хакерские решения. Большинство реактивных проектов включают babel для react-hot-loader (плагины компилятора), некоторые системы CSS также требуют babel для преобразований во время компиляции. Использование модулей pnp, esm или даже CSS требует дополнительных инструментов и обходных путей для ограничений tsc.

Разочаровывает также то, что по некоторым из этих вопросов сообщество предложило конкретные решения в виде PR или предложений, но они были отклонены или застопорились на годы. Практикующему специалисту становится все труднее использовать TS в контексте более широкой экосистемы.

В любом случае, я просто случайный человек из Интернета.

@DanielRosenwasser , может быть, https://github.com/microsoft/TypeScript/pull/29374 можно будет вовремя просмотреть для 4.0? Я думаю, что он охватывает многие (большинство?) случаев this -before- super , о которых обычно спрашивают люди.

Пожалуйста, пересмотрите возможность включения поддержки ссылок на модули ES с путем к файлу, включая расширение файла. Это даст большой импульс для выравнивания игрового поля кода с несколькими средами.

https://github.com/microsoft/TypeScript/issues/16577

Спасибо за внимание к инструментарию машинописного текста! Я надеялся, что вы рассмотрите возможность более тесной интеграции с https://github.com/microsoft/tsdoc. Многие другие современные языки, такие как go и rust, предоставляют инструменты для документирования прямо из коробки и поощряют разработчиков писать стандартные комментарии, но в этом отношении отсутствует машинописный текст.

Было бы супер здорово, если бы # 31445 можно было подобрать, это было нарушением условий сделки для нас, и я верю многим людям (исходя из того, сколько ссылок на этот выпуск)!

Можно ли включить https://github.com/microsoft/TypeScript/pull/38967 в TypeScript 4.0 и, возможно, также https://github.com/microsoft/TypeScript/pull/35608 .

Я обнаружил, что люди просят включить все в версию 4.0 😆

Чувствуете, что ТС теряет импульс? Нулевое объединение и короткое замыкание назначений для следующего, _major_, релиза 4.0.0? Больше нет больших целей и амбициозных идей?

Для следующего майора я ожидаю:

• Типизация с более высоким типом
• Зависимая типизация? Функции уровня типа? (Хорошо, это может быть для 5.0.0)
• Номинальная типизация
• Макросы
• Поддержка трансформеров в tsconfig.json
• Компиляция в WASM (некоторого языкового подмножества)

@canonic-epicure Согласитесь, в настоящее время это больше похоже на 3.10 для следующей версии.

Чувствуете, что ТС теряет импульс? Нулевые задания по объединению и сокращению для следующего крупного релиза 4.0.0? Больше нет больших целей и амбициозных идей?

TypeScript не следует за semver. Не существует версии 0.10, версии 1.10, версии 2.10 или версии 3.10. Так что это на самом деле нормальная веха. Немного странно, что люди ожидают так много изменений в 4.0, но ничего не говорят о 3.9 или предыдущем плане итерации. 🙈

Функции уровня типа

type X<T> = T может сделать это на каком-то уровне. (не поддерживает функции высшего порядка.)

Макросы

ИМО это не удовлетворяет цели машинописного текста.

Поддержка трансформаторов в tsconfig.json

Попробуйте: https://github.com/cevek/ttypescript

Компиляция в WASM (некоторого языкового подмножества)

Вы ищете https://www.assemblyscript.org/

Итак, 4.0.0 — это просто очередной второстепенный релиз, о котором приятно знать.

Что касается «макросов не удовлетворяют цели TS» и «используйте ttypescript для трансформеров» (кстати, ts-patch работает лучше) — это напоминает ход джедая — «это не та функция, которая вам нужна». Нет, макросы и трансформеры из коробки пожалуйста. Это было запрошено несколько лет назад.

Я также хочу использовать marco в TypeScript, но причин против этого очень много.

1. если Marco может генерировать другой код JavaScript, он создает новый синтаксис нетипового уровня, следовательно, это расширение спецификации ES. enum , import x = require(...) , module являются исключением из этого правила, но они появились в ранние времена TypeScript.

2. если вы хотите использовать Marco для пересечения разных файлов для создания разных файлов JS, то невозможно тупо отказаться от синтаксиса всех типов, чтобы получить файл JavaScript.

3. Маркос может увеличить время анализа и компиляции и, вероятно, подвергнется злоупотреблениям.

4. Если Marco сможет создавать разные JS-файлы на основе информации о типе, Babel не сможет обрабатывать этот синтаксис. Таким образом, такое поведение нарушает правило isolatedModules (исключение: const enum и module )

5. Если Marco может выполнять только «уровень типа Marco» и может быть безопасно стерт Babel, он становится бесполезным, но все же полезен для программных типов более высокого порядка. Поэтому это не нарушает никаких целей, но я сомневаюсь, что команда TypeScript заинтересуется этой идеей. (Я сделал демо на https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts).

@ Jack-Works Я не понимаю твоих мыслей. Возможно, вы имеете в виду, что макросы расширят парсер и создадут новый синтаксис?

Для меня макросы - это просто функция AST -> AST, которая каким-то образом запускает предыдущую проверку типов, поэтому она может создавать новые узлы AST, которые будут регулярно проверяться. Однако он не создает новый синтаксис — ввод — это обычный AST, вывод — тоже. Он создает новые узлы в AST.

Обсуждение будет не по теме этой ветки, возможно, будет продолжено на канале #compiler в дискорде?

Можно ли включить #38597 в TypeScript 4.0?

@ДаниэльРозенвассер

undefined в сигнатурах индексов — это пример чего-то интересного, но мы не хотим добавлять поведение, усложняющее работу 90% людей, которые уже работают с текущими предположениями.

Просто любопытно, откуда вы знаете, что это 90% людей?

@wongjiahau номер был составлен небрежно для объяснения. Не уверен, что это тот конкретный момент, о котором вы спрашиваете.

Сразу предупреждаю: наша команда не будет работать 19 июня, поэтому мы немного сдвинем график. Бета-версия теперь должна быть выпущена в следующий четверг, 25 июня.

@DanielRosenwasser Я пытаюсь указать, что вы используете некоторые выдуманные произвольные числа, чтобы отрицать важность функции (# 13778), которая явно согласуется с первой целью Typescript, которая заключается в том, чтобы статически идентифицировать конструкции, которые могут быть ошибки .

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

@wongjiahau , мы не пошли на собрание и не сказали: «Дэниел сказал, что число составляет 90%, это выше нашего порога в 85%, давайте никогда не будем использовать эту функцию». Мы все еще изучаем ее, и мы прекрасно знаем о спросе на нее со стороны разработчиков, но мы также проверили, как эта функция выглядит на практике, и я могу сказать вам, что она не очень хороша.

Если вы собираетесь чрезмерно анализировать подобные заявления от нас, вы просто получите меньше заявлений от нас, потому что у нас есть более важные дела, чем быть активно неправильно истолкованными в Интернете.

4.0 определенно является вехой, а не «следующей версией 3.9».

@typescript-bot создать версию 4.0

Привет @DanielRosenwasser , я начал создавать для тебя ветку release-4.0 . Вот ссылка на мое лучшее предположение в журнале .

@Kingwl , если это веха, то что это за важные вещи или, по крайней мере, что такое функция героя? Я не вижу ничего такого замечательного в списке функций языка в верхней части этого выпуска. Ничего необычного по сравнению с большинством релизов 3.x.
Конечно, можно сказать, что это просто критическое изменение, требующее выпуска основной версии, но тогда трудно назвать это «вехой».

@wgebczyk На мой взгляд, вариативные кортежи с помеченными элементами кортежа являются важной вехой.

@wgebczyk Неважно. Но на самом деле Variadic Tuples есть.

@xiaoxiangmoe @Kingwl верстовой камень? дюймовый камень.

Это там: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
Когда это достигнет стабильной версии? Я не могу дождаться, чтобы применить это в повседневном кодировании в VS Code.

@mk0y согласно вступительному сообщению о 18 августа.

@wgebczyk наши выпуски основаны на времени; каждый выпуск содержит примерно три месяца работы команды. Наша промежуточная политика управления версиями (n = n + 0,1) была неизменной для последних 20 выпусков, так что, надеюсь, в какой-то момент это перестанет быть сюрпризом для людей 😅

Не могли бы вы разрешить тип symbol для индексации в следующих второстепенных выпусках? Не могли бы вы актуализировать и объединить запрос на включение 26797 ?

Привет @DanielRosenwasser , я начал обновлять номер версии с release-4.0 до 4.0.1-rc для вас. Вот ссылка на мое лучшее предположение в журнале .

@typescript-bot синхронизирует версию 4.0

Эй, @DanielRosenwasser , я начал для тебя синхронизировать release-4.0 с мастером. Вот ссылка на мое лучшее предположение в журнале .

@typescript-bot синхронизирует версию 4.0

Эй, @DanielRosenwasser , я начал для тебя синхронизировать release-4.0 с мастером. Вот ссылка на мое лучшее предположение в журнале .

@weswighammmmmmmmmmmmmmmmmmmmm , бот меня ненавидит ): ): ): ):

Абсолютно никакой спешки, но я сделал это вручную и подал это: https://github.com/microsoft/TypeScript/issues/39869

Есть ли где-нибудь дорожная карта после 4.0? Я хотел бы поднять #37582, так как спрос все больше и больше растет (#39965, #38149, #27481, #39965, #38546). Мне это кажется разумно масштабной проблемой.

В качестве обновления нам пришлось перенести RC на 2 дня для запуска веб-сайта и для других изменений, которые, как мы чувствовали, нам нужно было приземлиться в RC. Мы не ожидаем, что что-то сильно оттолкнет нас назад, но на всякий случай мы дадим себе еще 2 дня, чтобы получить отзывы о RC, и вместо этого нацелимся на 20-е число.

@typescript-bot обновляет версию 4.0

Привет @DanielRosenwasser , я начал обновлять номер версии с release-4.0 до 4.0.2 для вас. Вот ссылка на мое лучшее предположение в журнале .

это 20 августа :)

Хех, здесь еще 19 августа, и даже через 20 минут, я думаю, вам придется подождать еще немного. У нас есть ночные релизы на npm, если вы не можете ждать ни минуты! 😄

Жду релиза, уже вышел в npm :)

@typescript-bot обновляет версию 4.0

Привет @DanielRosenwasser , я начал обновлять номер версии с release-4.0 до 4.0.3 для вас. Вот ссылка на мое лучшее предположение в журнале .

@typescript-bot обновляет версию 4.1

Привет @DanielRosenwasser , я начал обновлять номер версии с release-4.1 до 4.1.1-rc для вас. Вот ссылка на мое лучшее предположение в журнале .

о нет

@typescript-bot обновляет версию 4.0

Привет @DanielRosenwasser , я начал обновлять номер версии с release-4.0 до 4.0.4 для вас. Вот ссылка на мое лучшее предположение в журнале .

@typescript-bot обновляет версию 4.0

Привет @DanielRosenwasser , я начал обновлять номер версии с release-4.0 до 4.0.5 для вас. Вот ссылка на мое лучшее предположение в журнале .