Valen предлагает новый вид проверки заимствований, решающий конфликт между borrow checking и другими подходами
Valen's Memory Safety: A New Kind of Borrow Checking
Valen представляет гибкий borrow checker на основе Group Borrowing, который ослабляет правило shared-xor-mutable до запрета use-after-free. Компилятор запоминает, куда указывает ссылка, что позволяет безопасно использовать несколько изменяемых ссылок на один объект. Подход уже переняли Carbon, Ante, Zeta и другие. Valen также обеспечивает совместимость с Rust.
Borrow checking has the "shared-xor-mutable" restriction: if you hold a reference to an object, nobody else can change the object. Other approaches want to allow holding a reference to an object while letting others change it.
- kvark
Мне это больше напоминает заимствование «пути», чем «группы», но идея отличная! Прямо глаза открывает!
Одна мелочь: не уверен, зачем им понадобилось ключевое слово "in" для подзаимствований. Не было бы последовательнее видеть "entity &world.entities[?]" вместо "entity in world.entities[]"? Мы бы последовательно получали символ заимствования "&" и открыли бы дверь для некоторых контрактов о том, какой индекс (диапазон) затрагивается.
- zamalek
> Проверка заимствований имеет ограничение «shared-xor-mutable»: если у вас есть ссылка на объект, никто другой не может изменить объект.
В статье это подаётся как проблема. Это не так. Это ограничение избавляет вас от необходимости думать об определённых классах ошибок в конкурентном коде; именно отсюда берётся «fearless concurrency». R^w не о времени жизни — вы могли бы, в теории (не уверен насчёт практики), убрать его из Rust без какого-либо влияния на use-after-free.
Конечно, это означает, что вы не можете написать много совершенно корректных программ, и поэтому мы надеемся, что есть лучшее решение, но удаление его — не решение.
Если вы хотите об этом думать (и потенциально вносить ошибки), это совершенно нормально. Гибкость, когда не требуется r^w, чрезвычайно полезна. Я просто проясняю эту ошибочную атрибуцию.
- SleepyMyroslav
Это выглядит круто для систем, управляемых кодом, где код статически знает каждый путь в системе. Это может быть строго лучше для таких вещей, как рендеринг, где типы рендеринга управляются кодом. Например, в вашем мире может быть skybox и тому подобное. Однако примеры, предполагающие gamedev 'world' и 'entity', совершенно вводят в заблуждение. Потому что, я думаю, все уже перешли на миры, управляемые данными. Воспринимайте сущность 'advance' из примеров кода как 'выполнение blueprint сущности'.
- melodyogonna
Происхождение Mojo может представлять многие из этих семантик. Я думаю, многое было почерпнуто из предложения Nick, даже если оно не было напрямую реализовано. Вот пример того, как можно представить первый фрагмент, где две ссылки могут обновлять один и тот же список: https://godbolt.org/z/78bhzWjYM
- verdagon
Также, пока я это писал, мне пришло в голову несколько вещей:
* Мы _могли бы_ использовать синтаксис параметров функции `entities: &world.entities[]` вместо `entities in world.entities[]`.
* «Группы» на самом деле не центральны для понимания идеи, так что Path Borrowing может быть лучшим названием, чем Group Borrowing.
Мнения приветствуются =)