>[оверквотинг удален]
> в любой реализации кучи, которая отдельно следит за маппингом памяти, отдельно
> за занятыми виртуальными адресами.
> В данном частном случае, я отмечу, всё было сделано так, что в
> момент, когда страницы надо было анмапить, было невозможно решить надо ли
> анмапить или не надо, потому что владельцем этих страниц мог быть
> юзерспейс, если он мапил, или кернелспейс, если мапил он.
> То есть в ядре было понятно, что можно (и нужно) реклаймить виртуальную
> память из-под буферов и помечать свободной, а вот что делать с
> физической памятью уже было не ясно, потому что ключевая для принятия
> решения информация была утеряна к тому моменту.

Вот эту последнюю проблему и решает RAII. Всё освобождается в одном месте - деструкторе (а что именно освобождается - это вообще дело десятое). Но может так оказаться, что всё это затруднительно завернуть в одну обёртку. Потому что архитектуру проектировали под язык Си и без расчёта на такое. То есть я веду вовсе не к тому, что плюсы чудесным образом смогут гарантировать отсутствие ошибок. А к тому, что ради возможности обеспечения таких гарантий придётся переписывать вообще всё. И это язык очень близкий к Си технически, но вот такой нюанс немножко всё портит. Я не знаю, насколько верно из этого частного случая индуцировать обобщение на Rust, но оптимизма по этому поводу у меня нет. Особенно после того как местные знатоки языка честно признаются "а как в ядре, я не знаю".

>> Это без оптимизации. С оптимизацией bar() в принципе должна исчезнуть.
> Может исчезнуть, но может и нет. В данном примере код написан так,
> что он заинлайнится. Но не весь код инлайнится. Плюс оптимизации --
> это оптимизации, они не меняют семантики, а семантически есть промежуток времени
> выполнения, когда три валидные мутабельные ссылки мирно сосуществуют.

Ссылки эти просто висят в памяти, поскольку процессор сам собой её не зануляет. Они могут сыграть роль в фантастическом случае - руткит останавливает поток исполнения и начинает рыться в стеке, что бы найти там указатель и по нему что-то ещё модифицировать.

>[оверквотинг удален]
> move-конструктор в C++ получает ДВА указателя, и работает с обоими. Чтобы эти
> копии выкинуть, оптимизатор должен быть в состоянии отследить весь контрол-флоу, понять
> что память из под старого значения не используется больше, вернутся назад
> и повторно использовать память. И из-за этого невозможно просто присунуть в
> деструктор отладочную печать, и потом считать сколько раз деструктор вызывается, потому
> что наличие отладочной печати показывает оптимизатору, что память используется потом,
> и он не оптимизирует. Арггх, я ненавижу C++, его идея смешивать
> семантику с оптимизациями -- это просто слов у меня нет для
> описания идиотизма тех, кто это придумал. Они явно на каких-то тяжёлых
> веществах сидели в этот момент.

Я не уверен, что в плюсы обязательно тащить всё, что хорошо себя зарекомендовало в ООП-языках. Все эти константы просятся в специализацию шаблона. Вот это действительная проблема плюсов - когда свалили все парадигмы в кучу, а метапрораммирование умел один Александреску, но почему-то ушёл в D.