11lc — инновационный компилятор для нового языка программирования

Вообще, мне кажется, вы опять частично переизобретаете Rust:

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

2. При передаче в метод ссылки на объект это нужно явно указывать на вызывающей стороне (исключение -- если переменная и так имеет тип "ссылка", то никаких дополнительных значков при ее передаче не нужно. Т.е. все-таки только по тексту вызова не понять, может функция модифицировать переменную или нет).

3. Авторазрушение объектов после последнего использования -- для начала ознакомьтесь с не лексическими временами жизни (Not Lexical Lifetimes, NLL) в Rust. Тут сильно много неочевидных моментов. Автоматически уничтожать переменные после последнего использования -- сильно неочевидно. С чего вы взяли, что в примере кода

   f = open('output.cpp', 'w')
   f.write('int main() {}')
   os.system('g++ output.cpp')
   

   после os.system нужно в f вызвать финализацию? А если типом f будет mutex_guard? Будите отпускать его прямо перед выполнением защищаемой им операции?

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

Аллокатор -- это лишь интерфейс. Подсвеченная вами проблема только лишь в интерфейсе, который не возвращает реальный выделенный размер. Если его добавить в интерфейс, то проблемы нет.

Гарантированная оптимизация хвостовых вызовов -- пожалуй единственная здравая идея, которая еще ни в одном из мейнстримных языков не реализована. Только нужно более строгие гарантии дать -- гарантировать оптимизацию хвостовой рекурсии с аккумулятором. Тогда компилятор сможет даже рекурсивное вычисление последовательности Фибоначчи в цикл свернуть.

А ещё необходимо фиксировать версии библиотек - иначе, программы написанные пару лет назад собрать будет нереально, из-за необходимости угадывать версии. В идеале вообще нужно сделать так, чтобы можно было подключать одну и ту же библиотеку разных версий одновременно, например

From awesomelib-1.1.0 import foo

From awesomelib-2.1.1 import bar

Автоматически скачивать что-то при компиляции просто при упоминании -- это же готовый бекдор.

Ну, можно ведь как-то помечать модули в реестре и автоматически скачивать и устанавливать при компиляции только модули с пометкой trusted.

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

Если вы имеете в виду то, что при попытке обращения в коде к модулю с именем скажем backdoors_collection компилятор скачает и установит этот модуль без ведома программиста (а иначе увидев модуль с таким странным именем программист хорошо подумает, прежде чем устанавливать его), так это решается вот этой самой пометкой trusted, ибо никакой модуль с таким подозрительным именем [даже если в нём и не будет вредоносного кода] такую пометку не получит.

Т.е. думать ‘всё равно ’|надо|‘ в любом случае’. Просто есть два варианта:

1. Думать каждому программисту, безопасно ли подключать/устанавливать данный модуль/библиотеку.

2. Или думать только модератору реестра [или совету модераторов] ставить пометку trusted добавленному в реестр модулю или не ставить [очевидно, что по умолчанию trusted стоять не должно].

И тут, я считаю, второй вариант будет даже безопаснее.

А вообще суть идеи с автоустановкой модулей/пакетов в том, чтобы поощрять экспериментирование и упрощать обмен кодом: увидел фрагмент кода на Stack Overflow — вставил в свою программу и запустил (при этом не нужно ни лезть в начало исходного файла и дописывать в import имена модулей, которые используются в этом фрагменте кода, ни устанавливать эти модули).

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

Так я ж не против. Указывать это всё можно (как я и написал в статье: "Если требуется не последняя версия пакета/модуля, это можно указать в файле конфигурации/сборки проекта." [внутри спойлера "Немного технических подробностей"]).
Речь о том, чтобы указывать это [какие модули необходимы программе] было не обязательно.

Первый пример не до конца корректный. Если в словаре лежит не truethy значение - например False или какой нибудь response 404, то результат может быть неверный. Даже явная проверка на is not None может не помочь в случае, если в словаре лежит как раз None.
Второй пример более удачный, но может подавить лишние ошибки, если под этим менеджером контекста будет много кода.

В общем как по мне - явная поддержка такой конструкции в языке кажется неплохой идеей.

Удивительно, что до сих пор никто не увидел ошибку в вашем комментарии.
Для очевидности [в чём ваша ошибка], обернём код из статьи в функцию и добавим тестовый вывод для проверки корректности изменений кода:

dic = {1: 'a', 3: 'b', 4: 'c'}

def f(key):
    if key in dic:
        dic[key] += '...'

f(1)
f(2)
f(3)
print(dic)

А теперь попробуйте переписать этот Python-код таким образом, чтобы поиск key в dic внутри функции f всегда осуществлялся только один раз.

Потому что читабельный код это в том числе текст, который соответствует правилам дизайна текста.
Я не дизайнер, но мне кажется очевидным, что различные избыточные скобки, закорючки и прочие спецсимволы затрудняют восприятие текста. Если можно писать без скобок (так, что это не вредит пониманию кода), то лучше писать без скобок. Если можно писать and вместо &&, то лучше писать and. Если ты не математик, который в формулах, как рыба в воде, то такие вещи для тебя действительно визуальный мусор, затрудняющий восприятие.
Не думаю, что во времена создания C о таких вещах задумывались. (А ЕЩЕ В ТЕ ВРЕМЕНА СЧИТАЛОСЬ ХОРОШИМ ТОНОМ ПИСАТЬ ПРОГРАММЫ КАПСОМ, ДУМАЮ, СЕЙЧАС ДАЖЕ ДАЛЕКИЙ ОТ ДИЗАЙНА ЧЕЛОВЕК ПОНИМАЕТ, ЧТО ЭТО НЕ ОК)
А в наше время при создании языка нужно уделять большое внимание текстовому дизайну.
Потому что код пишется один раз, а читается много.

На Linux, кстати, был x32 ABI, но его по не очень понятным мне причинам похоронили. Возможно как-раз из-за таких проблем.

Тратятся ресурсы на сборку пакетов под этот ABI, а им никто не пользуется. Решили что нерационально поддерживать.

Вроде в C такое проходили в эпоху перехода с 16 на 32 бита.

Это было не в эпоху перехода, а в эпоху 16 бит. Тогда, напомню, в ходу была идиотски сделанная сегментная адресация, из которой и следовала необходимость двух типов указателей - "ближнего", содержащего только смещение, и "дальнего", содержащего ещё и селектор сегмента.

Выглядит так что сломает кучу старых программ. Будет вызываться другой код, который работает как-то по другому.

Нет уж, спасибо. static char BUF[256] - это один из главных типов уязвимостей в программах. Отчасти из-за этого некоторые регулирующие органы уже советуют не использовать C там, где требуется хоть сколько-нибудь безопасности и надёжности.

Речь о РОН или о SIMD? Пример такой оптимизации можно?

Но этот код имеет смысл, если функция принимает множество, внутри его изменяет

Как же она его изменяет, если это const std::set<int>? :)(:
Без const — да, имеет смысл (хоть и редко).

Резюмируя, в C++03 существует 4 способа передачи аргумента типа std::set<int> в функцию:

void f(std::set<int> st);
void f(std::set<int> &st);
void f(const std::set<int> st);
void f(const std::set<int> &st);

И вот третий из них — смысла не имеет.