Comments 44
Не знаю как ситуация была 2019, но есть struct - ваши классы; [что такое подтипы?]; интерфейсы с помощью функций внутри структур, которые принимают структуру как первый аргумент(тут правда проблемка - почему-то нельзя сделать приватными поля, не понял причин этого пока что);
В одной из статей по Zig написано, что он скорее антимодульный, чем модульный. Как я понял, он сделан с целью быть простым как Си, при этом исправить его недостатки. Я думаю с этой целью он хорошо справляется.
Дженерик компаил тайм, это большая киллер фитча. Не знаю, есть ли тут бинды к аст, что бы еше код в компаил тайм генерить, если есть, то язык стоит внимания.
Компилятор пока что написан на C++, хотелось бы чтобы портировали на Zig. Тогда дальнейшее развитие будет легче идти.
Под дженериками aka generic types и generic functions обычно подразумеваются некоторые шаблонные типы и функции, которые имея на входе другие типы могут исполниться в некоторой шаблонной функции.
То бишь вместо
fn add(a: int, b: int) -> int { a+b }
fn add(a: float, b: float) -> int {a+b}
можно написать просто
fn<T> add(a: T, b: T) -> {a+b}
и скармлвать в такую функцию хоть int
, хоть float
, хоть сложный тип у которого оператор сложения реализован/перегружен.
В C++ их обычно шаблонами зовут, например.
Собственно исполнение генериков подразумевает, что шаблон необходимо разернуть и вывести типы, что обычно проворачивает компилятор. Генерики в интепретируемых языках вроде не встречаются, поэтому я утверждаю что не компайл-тайм genericов не существует. Поэтому и спросил про альтернативные женерики в существующих языках программирования.
А насчет срезов. Не знаю есть ли они в GO, но они точно есть в Python.
Возможно оттуда и взято.
А вообще интересно конечно, спасибо за обзор :)
Срез — это невладеющая структура данных, отображение настоящего массива. Т.е. изменения элементов среза также должно изменять оригинальный массив. В именно го так, а в Python не так.
ps: есть такой тупой мультик
Union в такой реализации вообще какие-то бесполезные получаются.
Понравилось перечисление как пространство имен. Но все равно хочется для переменной A типа enum вызвать A.isSomething(). В D это решается передачей A в качестве параметра в функцию isSomething насколько я помню.
Понравился подход к обработке ошибок.
P.S. А почему «идеологически верно» писать тип переменной после ее имени?
P.S. А почему «идеологически верно» писать тип переменной после ее имени?
Мне вот тоже интересно.
С давних времен привык что везде тип переменной перед ее именем, и как-то совсем не понял почему перевернули наоборот.
var x: type = value
Здесь var/let/const — всегда известное ключевое слово, дальше имя, а тип опционален ибо в тренде автоматический вывод типов.
C++, Objective C, Java.
Ну а насчет того что так читается проще — довольно субъективное утверждение, дело привычки, возможно и так наверно.
Идиоматически верно, потому что в большинстве случаев можно написать что-то вроде const a = 3
или let a = vec.map(Impl::doStuff).collect()
и иже с ними и тип будет выведен компилятором автоматически.
умножение — я все ждал пока кто-то это реализует, и вот дождался:) В Ассемблере(!) есть такая операция dup, которая позволяет формировать повторяющиеся данные. Теперь и в Zig:
В Perl это давно есть:
print( "xxxaaa"x3 ) # выведет xxxaaaxxxaaaxxxaaa
Слайсы (Срезы)
Вроде бы это взято из Go, не уверен.
Снова очень похоже на Perl:
@a[ 1, 2, 7, 3 ] # Достать елементы массива. Вернёт значения в индексах 1,2,7,3
@x{'key1', 'key2'} # Достать елементы хеша. Вернёт значения ключей key1, key2
while,for
for (items[0..1]) |value| {
sum += value;
}
Думаю, что в далёком 2006 вот именно по этой причине я ушел с РНР на Perl:
for my $item ( @items[ 1..3, 7 ] ) {
print $item;
}
Оператор unreachable
Perl Yada-Yada operator?
...
Исполнение кода во время компиляции
В Zig предусмотрена мощнейшая возможность — выполнение кода, написанного на zig, во время компиляции.
Видимо всё новое — это хорошо забытое старое
Очень приятно что такие проекты появляются и развиваются.
Очень рад тоже. Это говорит о том, что сейчас создать язык становится тривиальной задачей, а следовательно количество языков будет расти. А как мы знаем: количество обязательно перейдёт в качество. Будем наблюдать.
Спасибо за статью.
Однако, все коды ошибок получают значения больше нуля; также, если объявить в двух перечислениях код с одним и тем же именем, он получит одно и то же значение.
Я правильно понял, что это пока динамической загрузке?
[1,2,3] * 5
[1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3]
1. структурированное программирования (ограничило прямую передачу управления — запрет goto куда попало)
2. объектно ориентированное прогр. (ограничило косвенную передачу управления)
3. функциональное прогр. (ограничело на присваивание)
Даже модели MVC ограничивают то что может происходить в модели, представлении и контроллере.
Пока в языке в явном виде не появятся объявления ограничений, за которыми будет следить компилятор, очередной революции не будет.
fn foo(condition: bool, b: u32) void {
const a = if (condition) b else return;
@panic("do something with a");
}
лучше чем эта:
fn foo(condition: bool, b: u32) void {
if (!condition) return;
const a = b;
@panic("do something with a");
}
?У меня претензия к примеру — он совершенно не раскрывает пользу такой записи.
В идеале, пример должен быть из реального проекта. И неплохо бы показать не только код, использующий данную возможность, но и код, который приходится писать без такой возможности.
Действительно интересная замена для си. Судя по официальной странице, автор выбил финансирование и работает над языком в полную смену. Для меня самыми интересными фичами оказались поддержка 80-точности чисел с плавающей точкой, длинная арифметика, арифметика с насыщением и векторные типы. Первая попытка скомпилировать dll и вызвать функцию из c# прошла удачно, но вот скомпилировать именно для 32-х битной платформы не получилось. Попозже может доберусь до более полноценных испытаний.
вложенные многострочные комментарии.
Видимо, с тех пор ни один разработчик языка не осилил такую несложную штуку:)
Где-то в доках есть другое объяснение. В каждой строке кода есть всё необходимое для её токенизации, нет зависимости от контекста. Отсюда многострочные комментарии сделаны однострочными и по этой же причине raw-строки также однострочные :| Видимо разработчик языка озабочен эффективностью компилятора. Имхо, можно было и поступиться в части комментов и строк этим правилом. С другой стороны, вставки комментов/строк решаемы поддержкой в IDE, а на читабельности это не скажется.
Язык программирования Zig