Anton
Приведи пример
Anton
Я бы даже нарисовал скоупы заимствований для наглядности
Anton
Только мне не в чем
Anton
Anton
Как-то так примерно
Anton
Лайфтайм ссылки mutable_ref двухуровневый. Внешний иммутабельный, и два внутренних мутабельных
Anton
Плюс ещё два иммутабельных лайфтайма от вызовов inspect(&s)
Anton
Надо просто проследить, чтобы голубые не пересекались с красными
Anton
Ну и учитывать что внешний голубой является родительским в данном случае для красных
Anton
Anton
Жду опровержений короче
Anton
Потому что я сам не до конца уверен
Anton
Но пока вроде бы всё логично
Cuno
Приведи пример
https://play.rust-lang.org/?gist=2fe5faac75c0b4773378cdc552098829&version=undefined
Cuno
такое должно компилироваться?
Anton
Сейчас попробую разобрать)
Anton
Так а что бы случилось, если бы скомпилировалось?
Cuno
Сейчас речь не про "что бы случилось", а про "возможно ли запруфать".
Anton
Ну мы же пруфаем на уровне одной функции только
Cuno
В этом коде невозможно запруфать, что на mutable_ref нет алиасов на момент на 41 строке.
Anton
Хм. Не понимаю почему
Cuno
Потому что ref_holder определяется динамически, в рантайме.
Anton
Точнее не понимаю, откуда они могут взяться
Anton
А если inspect перенести выше, чем let mutable_ref?
Anton
Что-то изменится?
Anton
https://play.rust-lang.org/?gist=3c81b5084276b33c7976903734d8f493&version=stable
Anton
Такое же компилируется
Cuno
Ну дак
Cuno
это именно тот подход, о котором тебе изначально говорили
Anton
В чём отличие от такого?
https://play.rust-lang.org/?gist=6ae7c2c2a50207b5b6d35733c43b42ef&version=stable
Cuno
вместо того чтобы городить сложные пруфы, просто ограничивай область видимости своей иммутабельной ссылки
Anton
Cuno
Так, ты значит предлагаешь выделить corner case
Cuno
для случаев, где вообще нет ни одной ссылки на значение такого же типа?
Cuno
потому что только в таком случае можно запруфать (точнее даже и пруфать не нужно)
Cuno
иначе нам каждую ссылку убивать нужно будет
Cuno
перед мутированием
Anton
Я предлагают анализ лайфтаймов мутабельных ссылок разбить на две стадии
Anton
Anton
В этом и соль
Cuno
Это несколько бесполезно
Anton
Ну это простой пример)
Cuno
В этом то и прикол
Cuno
в любом более-менее сложном этот анализ не сработает
Anton
Конечная цель у меня была: сделать возможным чтение переменных между yield'ами генератора
Cuno
потому что полюбому будет еще какая нибудь ссылка рядом, которую и убивать то не захочется
Anton
Ну как минимум в примере с кложей это было бы удобно
Anton
https://play.rust-lang.org/?gist=00b1a11ffbcf79e00d2c29614c423bd0&version=stable
Anton
Вот здесь мутабельность и иммутабельность чередуются в каждой итерации
Cat
Anton
Anton
Могу так же его подкрасить цветами
Cat
аа, переклинило на clojure
Anton
Но это какое-то время займёт)
Cat
мне кажется, операции с box будут проще, чем со ссылками на стеке
Cat
так что.. мб просто box?
Anton
А зачем?
Anton
Если и на стеке валидно
Anton
Почему?
Anton
У нас тело функции состоит из строчек
Cat
ну значит я опять не прав
Cat
вешать меня
Anton
В один момент времени две строчки не могут выполняться
Anton
Поэтому надо просто проверить, что времена, где ссылка меняется и где нет, не пересекаются по времени
Anton
Ничего не изменится же
Cat
realloc произойдёт же
Anton
И?
Anton
Приведи код
Cat
ссылки, которые были выше станут невалидными
Anton
А выше нет ссылок
Cuno
В данном случае нет ссылок, в этом и фича
Cuno
но это игрушечный кейс
Cat
но в event_handler есть же захват
Anton
Они между вызовами
Anton
И это отдельные получения ссылок на каждой итерации