Не хочется чтобы марсоход завис из-за невалидной ссылки или еще чего-то ...

Большое количество последних секюрити issues в основном из-за неправильной работы с памятью и было бы не плохо предложить решение проблемы фундаментальное а не только ввиде sanitizer-ов

На самом деле спор разрешить довольно просто. Попробуйте накидать реализацию такого графа для clang. Если это действительно несложно, то с готовой реализацией можно смело писать предложение в комитет.

И кто его там будет лобировать ?

Я уже написал сборщик мусора поверх clang, как опцию для быстрого прототипирования и который ведет себя предсказуемо

У С++ коммитета не удобно следить за предложениями в последнее время из-за отказа от Google Group

Есть представители комитета от России: https://stdcpp.ru

Мне не очень удобно к вам заходить так как я с Украины

Но через Тор открывается конечно ...

Здесь в чате есть и представители комитета, например, Антон Полухин. Можно написать им напрямую.

Вообще даже само наличие такой реализации, пусть в прототипе, было бы очень круто. Если Вы уже работали раньше с clang и реализовывали GC, то знакомы с его структурой, это очень поможет.

Поймите меня правильно, я это пишу искренне. Если такой механизм предложат в С++, я обеими руками буду голосовать за. В Rust он действительно мощный. Просто у меня есть большие сомнения как в простоте его реализации, так и в том, что его можно безболезненно внедрить, не ломая совместимость со старым кодом.

Конечно идеально его не совместить со старым кодом, полноценное решение потребует перекомпиляции проекта с добавлением аттрибутов ... Но и преимущества громадные, компилятор действительно будет нашим другом )

Проблема ведь в том, что не всё даже можно перекомпилировать. В больших проектах часто десятки сторонних библиотек, либо проект зависит от них через shared objects. То есть для нормальной работы ему нужны будут версии этих библиотек, тоже пересобранные с новым компилятором.

Преимущества значительные, полностью согласен. Меня самого очень радует, что в Rust при нормальной работе с временем жизни баги вида use-after-move невозможны, я на них в своё время заработал пару седых волос :) Но мне кажется, что добавить это в стандарт действительно непросто именно из-за боязни поломать обратную совместимость или сделать фичу непригодной.

К сожалению, если сегодня даже для исправления unique_ptr или std::regex комитет не готов ломать ABI, то такое фундаментальное нововведение наверняка отвергнут. И это тоже играет против С++ в долгосрочной перспективе.

Стало очень любопытно, а он где-то выложен в открытый доступ, или это было по работе?

Да конечно
https://github.com/redradist/cpp_gc

Но от не совсем оптимальный так как обход графа запускается каждый раз когда уменьшается счетчик ссылок до 0 ... но зато Deterministic

Спасибо!

Может попозже расширю его до обычного сборщика муссора что бы пользоватьль могу выбирать

И еще я ему попозже API поменяю чуть чуть, сильно мне самому не нравится .create_object() -> можно спокойно использовать похожую функцию по названию как в стандарте make_gc например ...

Ну как же. Паттерн матчинг во всю стараются втащить в C++23

Нельзя, на манглинг есть стандарт, там тоже нельзя вносить ломающие изменения. И проверка не обычная, а требующая ручной разметки владений объектов (поэтому в раст и есть это адовое количество всяких закорючек, для описания лайфтаймов)