Комментарии 25
Например, зачем явно указывать тип переменной если ее тип компилятор может определить сам во время компиляции.
#include <cstdio>
template <typename T>
T foo(T val)
{
return val;
}
int main()
{
auto val = 1;
printf("Value: %d", foo(val));
return 0;
} Или даже так, если что-то поновее:
#include <cstdio>
auto foo(auto val)
{
return val;
}
int main()
{
auto val = 1;
printf("Value: %d", foo(val));
return 0;
} Но это довольно непрозрачный и плохой код, т.к. читателю не понятно, какой тип имеет val — unsigned или signed? Размерность 8, 32 или 64 бита? Надо знать как язык (и порой как конкретный компилятор для конкретной платформы) эти типы выводит, что особенно ужасно, если это код, который могут смотреть новички или люди, которые знакомы не конкретно с этим, а с другими языками.
Поэтому преимуществом это если и можно назвать, то очень не всегда.
Меня тоже удивило, что автор статьи этим утверждением обесценил строгую систему типов. Не стоит забывать, что компилятор делает проверки и показывает предупреждения в случае несоответствия типов аргумента:
void foo (unsigned x=0);
int y = 42;
foo(y); //warning: signed/unsigned mismatch
автор статьи этим утверждением обесценил строгую систему типов
Автоматический вывод типов не имеет к строгости системы никакого отношения.
В Haskell к примеру точно также можно нигде тип не указывать явно, и менее строгим он от этого не становится, тип все тот же, как если указать его явно.
Автовывод типов/явная типизация, строгая/слабая типизация, статическая/динамическая типизация, всё это три разные вещи которые постоянно между собой путают.
Сама по себе тема вполне интересная, но есть два "но":
1. Автору стоит поработать над изложением (вычитывать текст, проверять орфографию). Даже если закрыть глаза на орфографию, то в некоторых местах сломана логика повестования, например вот тут конец предложения словно вырван из другого места:
Это удобно для проверки кода без "долгой" компиляции и когда код готов, сгенерировать выполняемый файл (EXE)
2. Опущено гигантское количество внутренних деталей — то, что на Хабре бы очень оценили. Сейчас пост очень короткий и малоинформативный. Было бы интересно узнать, например, с какими проблемами автор столкнулся при генерации кода, насколько готов проект, какие подводные камни (например, насколько и как именно проект отступает от спецификаций). Можно было написать про стандартную библиотеку, которая уже существует и/или планируется.
В конце концов, TypeScript это лишь очень продвинутый тайпчекер, и поставить его на "рельсы" самостоятельного исполнения (без движка JS) это очень большая задача, о которой можно много рассказать.
но для любителей TypeScript синтаксис С/C++ имеет много ненужных вещей. Например, зачем явно указывать тип переменной если ее тип компилятор может определить сам во время компиляции.Эм, люди выбирают TypeScript вместо JS как раз (частично) потому что там типы есть, а вы их наоборот не указываете 🤔
авто-определение типа — это не тоже самое что "не указываю". Вот в примере "foo(val = 0)" "= 0" говорит о то, что "val" будет целым 32битным числом со знаком (т.к. это тип целого по умолчанию). Поэтому писать код "type int = 0; foo(val: int = 0) {}" долго и не удобно. и дает одинаковый результат для проверки и компиляции
Сишное
int foo(int val)Не эквивалентно
function foo(val = 0)это если думать о ECMAScript то да. Но tsc компилятор не пытается повторить поведение ECMAScript а использует синтаксис TypeScript-а для компилирования нативного кода. т.е. val будет получать только "int" значения. если хочется передавать любые значения тогда надо писать "function foo(val: any = 0)"
Ваш пример как раз ни о чём не говорит в отрыве от конкретной имплементации. Если не смотреть в документацию, то откуда вы знаете, что там будет именно целое 32 битное число?
Ноль не обязательно в знаковом типе хранить, поэтому там вполне можно использовать и unsigned int.
В C, к примеру, тип int по стандарту должен содержать "at least" 16 бит, т.е. там не факт что и 32 даже будет даже если это действительно int. А если сделать жадный компилятор, который выбирает типы на основе возможных интервалов значений, то ноль можно и вовсе в 1 байт поместить, чтобы лишние 3 байта не тратить.
В Lua все числа представляются через double, поэтому число там не целое будет.
В JavaScript, по-моему, Number — это тоже double. Учитывая то, что взрослый TS транспайлится как раз в JS, тогда тут ещё вопрос возникает, откуда там взялись целые 32 битные числа.
Такие угадайки разве удобнее для читателя кода будут, чем написать сразу какой вы там тип хотите?
вы все верно сказали. но 32 бита для "int" используется автоматически из-за "выравнивания" и поэтому что бы использовать int16 нужно указать свой тип например: type int16 = 65535; и когда компилятор будет использовать 16 бит а не 32. Это некоторые особенности конкретной имплементации TSC и да это все нужно описывать в документации
Хм, уже название исполняемого файла спорное. Точно такое же название и у компилятора в js.
Судя по всему, большая часть компилятора написана oduzhar. Можно поинтересоваться, чей же это проект на самом деле? Кто в действительности этот mlir-гуру который затащил ажно целый typescript?
Это один и тот же человек просто так получилось, что в одном броузере был один аккаунт, а в командной строке другой. Проект еще не закончен. там много еще чего делать, например - темплейты, юнионы, оптимизация для GC. ref. counter стратегия и так далее. работы на много лет. нужна помощь а ее нет.
Ой, я понял, это две учётки одного человека. Александр, это очень круто, огромная качественная работа.
TypeScript Native (AOT) Compiler