Предложение по улучшению

[hagz0r]

Я хочу чтобы программы на языке С++ выполнялись быстрее, были безопасными и не допускали ошибок!

Примеры мы можем увидеть в реализации таких языков как Rust, JavaScript.

Код:

fn main() {
  println!("Make C++ faster!");
}

console.log("Make C++ faster!")

Полезные ссылки:

• https://quick-bench.com/ - онлайн бенчмарк, поможет вам продемонстрировать эффективность вашего подхода
• https://godbolt.org/ - онлайн дизассемблер
• https://eel.is/c++draft/ - черновик стандарта C++ с возможностью ссылаться на конкретные параграфы
• https://wg21.link/ - универсальная ссылка на международные proposal или баги в С++, например https://wg21.link/P1000 ссылается на документ P1000, а https://wg21.link/cwg100 на 100 баг в ядре языка

[ansa-sequence]

Я думаю, что мы можем улучшить данную рекоммендацию до уровня пропозала с конкретными решениями по улучшению, но мне кажется, что в данный момент у Рабочей Группы С++ нет времени для данных импрувментов. Так что, тикет выглядит как солюшен в долгосрочной перспективе, но не возможен в данный момент.

[kirillsurkov]

Предложение очень хорошее! Но, к сожалению, это сломает ABI.

[kov-serg]

Я хочу чтобы программы на языке С++ выполнялись быстрее, были безопасными и не допускали ошибок!

Это в принципе не возможно по определению просто из-за постулатов заложенных в стандарте. Где вы видели большую программу на C++ без UB?
Что бы хоть как-то улучшить язык надо добавить фаз компиляции. Хотя бы отделить синтез кода от компиляции, а не присовывать всё в шаблоны, макросы и концепты пихая всё в кучу. Тоже самое касается и профилирования и оптимизации и проверок. Это должны быть отдельные фазы сборки. Более того пора бы уже добавить динамическую линковку функций с разными abi и ограничениями, а не просто по имени. Так как уже давно есть заопарк вариаций архитектур. Что мешает использовать обычную базу данных для поиска требуемых библиотек по имени функции и если такой нет собрать под нужную по мере надобностии, а не таскать фалый библиотек (которые сжимаются в сотни раз, что нимекает на чудовищную избыточность) с тьмой с суффиксов типа rv64imafdc_zicsr_zifencei. Да и клинковке есть вопросы почему нельзя указать опцию весь такой-то (селектор) namespace собери в отдельный файл и подгружай его динамичеси.
По поводу сломает ABI, так добавте механизм управления и контроя ABI.

[neromoonnn]

Выглядит как предложение по созданию нового языка программирования, который никак не будет связан с C++ и C. А без связи с C в том или ином виде (нативная поддержка, FFI), язык скорее всего будет никому не нужен. Выглядит как план на следующие пол века+ вперёд: разрабатываем новый язык -> разрабатываем новое ядро операционной системы на этом языке -> все дружно переходим на новое ядро и радуемся жизни. А потом, через неопределённое время, придёт человек с другими взглядами на то, как это можно было бы сделать и цикл повторится. Как можем видеть, пока что такого не произошло, ядру линукса 30 с небольшим и никто не планирует переписывать его с целью замены на глобальном рынке. Так что сомневаюсь, что предложение хоть когда то выстрелит, но надежда есть.