Выше уже отметил, что тип пишется после var, чтобы можно было объявить несколько переменных с одним типом.
Тип возвращаемого значения после описания аргументов функции, как мне кажется, более логичен.
имена фундаментальных типов специально включают разрядность, для наглядности, чтобы не вспоминать, сколько там байт в каких-нибудь shot, long.
Я тут исхожу из принципа, что все значения фундаментальных типов равозначны, а значит нельзя выбрать какое-то значения для умолчательной инициализации. Поэтому программисту явно надо указать, какое начальное значение ему нужно.
На счёт удобства — спорно. ак подсказывает мой опыт, чаще всего переменные объявляются сразу с инициализатором, где инициализатор это не просто какое-то число (вроде нуля) а значение сложного выражения, результат вызова функции и т. д. Случаи, когда мы объявляем переменную и только потом в неё что-то записываем редки, в основном это случай с аккумулятором для цикла.
Чтобы проверить компилятор на больших проектах, нужны большие проекты. Ну хотя бы какие-то проекты. Но таких пока нету.
Самокомпиляции в ближайшее время не будет, т. к. во-первых, для этого надо переписать весь компилятор, а во-вторых, надо будет написать биндинги для llvm.
Я вот 100 лет ждал возможность написать код в стиле
Читать такое бывает сложно.
Это что за зверь?
Ну это когда надо писать impl SomeTrait for SomeStruct{}. Мне больше нравится подход из C++ шаблонов — соответствие требованиям к типу определяются по необходимости, скажем, если вызвали std::sort, то будет использован operator<, и не обязательно наследовать тип от какого-нибудь Ordered.
От наследования реализации обычно больше проблем нежели достоинств
Действительно, можно перемудрить с наследованием. Но мне кажется, достоинства от наличия наследования всё же перекрывают недостатки от возможности его неправильно использовать.
отсутствие ссылок немного смущает
Ссылки есть. Нету ссылочных типов.
странный выбор синтаксиса
В начале разработки так и было, тип аргумента функции указывался после двоеточия. Но потом я пришёл к выводу, что двоиточие тут лишнее и не несёт особой смысловой нагрузки, а если двоеточие убрать, то логичнее будет указывать на первом месте тип аргумента, а имя на втором.
Конкретно это не фатальная ошибка, но существенная потеря, в сравнении с другими языками, где наследование есть. В языках с наследованием довольно просто осуществляется динамическая диспетчеризация за счёт механизма виртуальных функций, в Rust же надо использовать Trait Object, что, как мне кажется, не совсем изящно.
Данное упрощение ещё и читаемость кода упрощает, глаз сразу видит, где объявление переменной, а где что-то другое.
добавил бы литералы
Можно, но это пока не в приоритете.
null-safe оператор
Есть встроенный макрос if_var(){}, который достаёт из опционального значения объект, если он там есть, и выполняет содержимое блока для него. Возможно, это не так изящно, но суть примерно та-же.
Систему типов взял бы из java – все методы виртуальные
Все фунцкии виртуальнуе — это ущерб производительности, это противоречит заявленным целям.
ля синхронизации потоков стоит или на уровне ЯП определить конструкции
в язык такое, без должной необходимости, лучше не тащить. Но вот в стандартной библиотеке такое можно.
Да, вы верно подметили, немецким языком увлекаюсь.
там в коммитах везде транслитом русские слова
Использую такое для личных целей. Нужно это затем, чтобы не переключать часто раскладку клавиатуры. Символы с диакритикой есть в моей раскладке клавиатуры, отчасти поэтому у меня не вызывает проблем напечатать название языка.
Для объявления нескольких переменных одного и того же типа:
var i32 x= 0, y= 1, z= 2;
В вашем примере потребовалось бы для каждой переменной указывать тип, ну или не указывать и выводить тип из инициализатора, но тогда пострадает читаемость.
Предупреждений, пока что нету, только ошибки. Как мне кажется, лучше немного затруднить написание отладочных конструкций, чем оставлять лазейки безопасности.
На счёт проблем с печатью на английской клавиатуре названия языка — да, есть такое. Но, пока что, особой проблемы я в этом не вижу, т. к. гуглить по этому языку пока что нечего.
А когда (и если) язык станет хоть немного извесным, я убеждён, что можно будет каким-то способом эту проблему побороть.
Сейчас используется "*.u". Но завязки на расширение в компиляторе нету, можно как угодно файлы именовать, компилятор их в любом случае попытается скомпилировать.
вам не нужно ловить исключение на каждой же строчке.
Не нужно ловить там, где после каждой строчки состояние будет валидным. Если же переход из валидного состояния A в валидное состояние B требует выполнения операций i, j, k, и во время выполнения операции j возникло исключение, то возникнет невалидное состояние. Чтобы такого не было в среде с исключениями, надо ловить исключения каждой промежуточной операции и откатывать состояние до валидного.
исключения можно обрабатывать на том уровне, где это осмысленно
Я бы даже сказал не просто можно, а нужно. У нужный уровень это тот, на котором происходит вызов. Получается, исключения, которые пролетают несколько уровней стека вызовов, не нужны.
можно вернуть Some(null)
Вот именно, «вернуть». На счёт выбора механизма уже нету сомнений. Есть сомнения в типе, но так и с исключениями есть такие сомнения.
Действительно, жажда велосипедостроения у меня присутствует, скрывать не стану.
На счёт перечисленных вами языков: о Nim я немного читал, обнаружил в нём сборщик мусора. Это противоречит моим представлениям об идеальном языке. С Crystal и Zig не знаком, обращу на них внимание.
Указателей не то чтобы нету, их нету как составной части языка. Есть библиотечный шаблонный класс для сырых указателей, для всяких низкоуровневых вещей его можно использовать. Но это только для unsafe кода.
При работе с WinAPI, файлами, сетью можно (отчасти) обойтись ссылками. Там где обойтись ссылками будет нельзя, придётся писать свои биндинги.
Вообще, взаимодействие с кодом на других языках это отдельная тема, которую я раскрою позже.
Ключевое слово необходимо для упрощения синтаксического разбора. В Ü грамматика контекстно-свободная, а значит по ходу выяснить, что i32 это имя типа, а не что-то ещё, не возможно.
Тип возвращаемого значения после описания аргументов функции, как мне кажется, более логичен.
имена фундаментальных типов специально включают разрядность, для наглядности, чтобы не вспоминать, сколько там байт в каких-нибудь shot, long.
На счёт удобства — спорно. ак подсказывает мой опыт, чаще всего переменные объявляются сразу с инициализатором, где инициализатор это не просто какое-то число (вроде нуля) а значение сложного выражения, результат вызова функции и т. д. Случаи, когда мы объявляем переменную и только потом в неё что-то записываем редки, в основном это случай с аккумулятором для цикла.
Самокомпиляции в ближайшее время не будет, т. к. во-первых, для этого надо переписать весь компилятор, а во-вторых, надо будет написать биндинги для llvm.
Ну это когда надо писать impl SomeTrait for SomeStruct{}. Мне больше нравится подход из C++ шаблонов — соответствие требованиям к типу определяются по необходимости, скажем, если вызвали std::sort, то будет использован operator<, и не обязательно наследовать тип от какого-нибудь Ordered.
Действительно, можно перемудрить с наследованием. Но мне кажется, достоинства от наличия наследования всё же перекрывают недостатки от возможности его неправильно использовать.
Ссылки есть. Нету ссылочных типов.
В начале разработки так и было, тип аргумента функции указывался после двоеточия. Но потом я пришёл к выводу, что двоиточие тут лишнее и не несёт особой смысловой нагрузки, а если двоеточие убрать, то логичнее будет указывать на первом месте тип аргумента, а имя на втором.
Можно, но это пока не в приоритете.
Есть встроенный макрос if_var(){}, который достаёт из опционального значения объект, если он там есть, и выполняет содержимое блока для него. Возможно, это не так изящно, но суть примерно та-же.
Все фунцкии виртуальнуе — это ущерб производительности, это противоречит заявленным целям.
в язык такое, без должной необходимости, лучше не тащить. Но вот в стандартной библиотеке такое можно.
Больше всего данных для принятия решения по месту возникновения ситуации. Выше по стеку вызовов данных становится всё меньше.
Использую такое для личных целей. Нужно это затем, чтобы не переключать часто раскладку клавиатуры. Символы с диакритикой есть в моей раскладке клавиатуры, отчасти поэтому у меня не вызывает проблем напечатать название языка.
В вашем примере потребовалось бы для каждой переменной указывать тип, ну или не указывать и выводить тип из инициализатора, но тогда пострадает читаемость.
Совсем убрать нельзя, в шаблонах без него тяжело будет. Злоупотребление auto пока что останется на совести автора кода.
Такого хотелось бы конечно, буду работать над этим.
Второй случай — функция с пустым телом.
А когда (и если) язык станет хоть немного извесным, я убеждён, что можно будет каким-то способом эту проблему побороть.
Сейчас используется "*.u". Но завязки на расширение в компиляторе нету, можно как угодно файлы именовать, компилятор их в любом случае попытается скомпилировать.
Я бы даже сказал не просто можно, а нужно. У нужный уровень это тот, на котором происходит вызов. Получается, исключения, которые пролетают несколько уровней стека вызовов, не нужны.
Вот именно, «вернуть». На счёт выбора механизма уже нету сомнений. Есть сомнения в типе, но так и с исключениями есть такие сомнения.
На счёт перечисленных вами языков: о Nim я немного читал, обнаружил в нём сборщик мусора. Это противоречит моим представлениям об идеальном языке. С Crystal и Zig не знаком, обращу на них внимание.
При работе с WinAPI, файлами, сетью можно (отчасти) обойтись ссылками. Там где обойтись ссылками будет нельзя, придётся писать свои биндинги.
Вообще, взаимодействие с кодом на других языках это отдельная тема, которую я раскрою позже.