Убийца ли C язык C3?

PHP какой то =)

extern fn void printf(char *fmt, …);

А если где то лежат два модуля и в каждом свой printf?

БЛЯ

(простите меня, но иных слов и более ёмких определений нет)

Это я выбрал неудачный пример. :) Вот, например, векторы:

extern fn void printf(char*, ...);

fn void main()
{
    float[<3>] v1 = { 1, 2, 3 };
    float[<3>] v2 = { 4, 5, 6 };
    float[<3>] v3 = v1 * v2;

    foreach (i, a : v1)
    {
        printf("v1[%d]: %f\n", i, a);
    }
    foreach (i, a : v2)
    {
        printf("v2[%d]: %f\n", i, a);
    }
    foreach (i, a : v3)
    {
        printf("v3[%d]: %f\n", i, a);
    }
}

retaining the same syntax as far as possible.

only change where there is a significant need.

struct
{
} // no ;

fn void main()

…

Херня, пусть уже запилят C4. Вот это будет бомба.

модули - нет хидерам

extern fn void printf(char *fmt, …);

ЛОЛ, спасибо, но нет.

Дык С3 давно отметилась в семейке.

А каких ещё убийц вы знаете? Я только Rust и Zig.

Не к ночи упомянутый Odin и вечноразрабатываемый Jai от Джонатана Блоу.

Hare, который от Drew DeVault’а:

https://harelang.org/blog/

Покажи рефлексию.

Ну нинаю, сишка с удобствами. Стоит ли оно того хз. Умножать вектора весело конечно, но если надо в ином порядке то один фиг делать функцию. foreach тоже да удобно, но при желании он реализуется и в сишке, да не универсально будет, но оно и надо то местами. Зайдёт тем кто именно стремится и рыбку съесть и на … и сишкой пользоваться дальше и избавится от ручного труда (который опять же только в определённых случаях будет избавлен)

Ну пусть будет, посмотрим как оно будет или тихо сгинет в небытие =)

Cyclone

вот https://www.youtube.com/watch?v=_xWY4yWYApY

Ну нинаю, сишка с удобствами.

Неудобств тоже хватает. Например, невозможно скомпилировать файл true.c3, т.к. имя зарезервировано. Или члены enum должны быть ТАКИМИ.

Пока не могу переубедить автора в том, что это плохой дизайн.

Сыровато как-то. Подождём С5-С6.

printf(«12! = %d\n», x);

Это провал. Сколько уже было багов в printf. Первое что нужно делать это запилить правильное форматирование строк по типу print("{x}") вместо print("%d", x).

C

factorial(n) {
  return !n ? 1 : n * factorial(n - 1);
}

main() {
  int x = factorial(12);
  printf("%d\n", x);
}

Запланировано, но мечусь между портированием на C3 Ryu и Dragonbox. :)

А если так:

macro int @cofefe(a; @body(x))
{
    @body(a);
    @body(a);
    return 1;
}

fn void main()
{
    int x = 0;
    @cofefe(1; int y)
    {
        defer printf("defer: %d\n", x++);
        printf("%d\n", x++);
    };
    printf("Done!\n");
}

Вау, новый язык программирования!

Ну как бы нет, по крайней мере они не называют себя убийцами Си.

Подписывайтесь, ставьте лайки звёзды, шлите PR. :)

Подождите, а язык C2 уже был?

Из недостатков - практически спартанская стандартная библиотека

Может оно и к лучшему, для всяких там эмбедов

Ага.

Тут есть нюансы: ограниченный встроенный ассемблер. Пока нельзя в/из него передавать/получать параметры/значения.

К примеру, в Zig он полноценный и syscall им и реализован.

А в Odin есть и ассемблер и встроенная функция syscall.

нет. языки, плохо выглядящие эстетически (например, использующие знаки $ и % рядом с альфонумериком), могут иногда жить долго, но в конце концов загибаются, потому что их неэстетичность снижает продуктивность программистов, которые имеют дело с этим кодом. в случае же с новым языком, шанса взлететь нет. в отличии от php в своё время, никаких киллерфич по сравнению с любым c++, rust-ом или go.

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

а операторы - это дело десятое.

например, использующие знаки $ и % рядом с альфонумериком

$ означает, что это compile-time переменные.

Уже есть грамотно спроектированные Swift и D

D «убивает» C++, да ещё и со сборщиком мусора.

дженерики

Надеюсь не те, которые type erasure?

Такие:

module gen <Type>;

fn Type mult(Type x)
{
    return x * x;
}

fn Type addMult(Type x, Type a, Type b)
{
    return x * a + b;
}

module test;

define intMult = gen::mult<int>;
define doubleAddMult = gen::addMult<double>;

fn int getIt(int i)
{
    return intMult(i) + 1;
}

fn double getIt2(double i)
{
    return doubleAddMult(i, 2, 3);
}

А можно ли проверить у типа, что у него есть/перегружен оператор «*» Увидел:

Note: constraints are not feature complete

у него есть/перегружен оператор «*»

Уточню, что перегрузки арифметических операторов пока нет.

Добавлю, что compiler-benchmark поддерживает C3, но автор благоразумно не включил его в результаты. Потому что c3c один из быстрейших компиляторов. ;)

Будто это что-то плохое

он просто нифига не умеет же, вероятнее всего.

Казалось бы, в чем проблема сделать улучшенный Си учитывающий накопившуюся практику, но нет.

Видимо разруха в головах.

   float[<3>] v1 = { 1, 2, 3 };
   float[<3>] v2 = { 4, 5, 6 };
   float[<3>] v3 = v1 * v2;

А какое тут произведение векторов? Скалярное, векторное или тензорное?

В чем смысл такое в язык тащить?

Если результат произведения - вектор, то очевидно векторное.

очевидно векторное.

очевидно жеж, что покомпонентное произведение, в духе векторных процессоров. а то он умрет считать векторное произведение для векторов размерности тыща… и вообще не его это дело.

В чем смысл такое в язык тащить?

Если LLVM предоставляет такие возможности, почему бы их не использовать?

SIMD есть и в Odin и в Zig, да и в C++20 включили. Очевидно, фича востребованная.

понятно

Убеди автора что ключевые слова fn, let итп очень-очень вот прям совсем не нужны! И $ лучше выкинуть.

Вместо fn пока можно использовать func, let отсутствует. Насчёт бакса согласен. :)

это тебе не нужны, …если б ты хоть раз написал грамматический разбор.

я писал компилятор своего яп с си-подобным синтаксисом