Cuno
А я хочу сделать скоуп дырявым
Динамический полиморфизм и всё, не отследишь ты скоуп.
Anton
Приведи пример
Anton
Я бы даже нарисовал скоупы заимствований для наглядности
Anton
Только мне не в чем
Anton
Anton
Как-то так примерно
Anton
Лайфтайм ссылки mutable_ref двухуровневый. Внешний иммутабельный, и два внутренних мутабельных
Anton
Плюс ещё два иммутабельных лайфтайма от вызовов inspect(&s)
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
В чём отличие от такого? https://play.rust-lang.org/?gist=6ae7c2c2a50207b5b6d35733c43b42ef&version=stable
Ну вот здесь я ограничил, но оно же не скомпилируется
Cuno
Так, ты значит предлагаешь выделить corner case
Cuno
для случаев, где вообще нет ни одной ссылки на значение такого же типа?
Cuno
потому что только в таком случае можно запруфать (точнее даже и пруфать не нужно)
Cuno
иначе нам каждую ссылку убивать нужно будет
Cuno
перед мутированием
Anton
Я предлагают анализ лайфтаймов мутабельных ссылок разбить на две стадии
Anton
В этом и соль
Cuno
Это несколько бесполезно
Anton
Ну это простой пример)
Cuno
В этом то и прикол
Cuno
в любом более-менее сложном этот анализ не сработает
Anton
Конечная цель у меня была: сделать возможным чтение переменных между yield'ами генератора
Cuno
потому что полюбому будет еще какая нибудь ссылка рядом, которую и убивать то не захочется
Anton
Ну как минимум в примере с кложей это было бы удобно
Anton
https://play.rust-lang.org/?gist=00b1a11ffbcf79e00d2c29614c423bd0&version=stable
Anton
Вот здесь мутабельность и иммутабельность чередуются в каждой итерации
Anton
Могу так же его подкрасить цветами
Cat
аа, переклинило на clojure
Anton
Но это какое-то время займёт)
Cat
мне кажется, операции с box будут проще, чем со ссылками на стеке
Cat
так что.. мб просто box?
Anton
А зачем?
Anton
Если и на стеке валидно
Cat
Если и на стеке валидно
нельзя доказать, что во все моменты валидно
Anton
Почему?
Anton
У нас тело функции состоит из строчек
Cuno
нельзя доказать, что во все моменты валидно
box эту проблему не решает, данные то шарятся
Cat
ну значит я опять не прав
Cat
вешать меня
Anton
В один момент времени две строчки не могут выполняться
Anton
Поэтому надо просто проверить, что времена, где ссылка меняется и где нет, не пересекаются по времени
Cat
В один момент времени две строчки не могут выполняться
замени state.x += ... на vec.push() и сразу станет грустно
Anton
Ничего не изменится же
Cat
realloc произойдёт же
Anton
И?
Anton
Приведи код
Cat
ссылки, которые были выше станут невалидными
Anton
А выше нет ссылок
Cuno
В данном случае нет ссылок, в этом и фича
Cuno
но это игрушечный кейс
Cat
но в event_handler есть же захват
Anton
но в event_handler есть же захват
Да, но в момент его вызова ссылок нет
Anton
Они между вызовами
Anton
И это отдельные получения ссылок на каждой итерации