> Повесишь внутри функции onclick на элемент.. а Раст его по завершению функции почистил"его" -- это кого? Элемент? Каким образом этот элемент попал в функцию? Был создан в ней, и никуда не передан? Да, тогда rust его просто удалит. Или может ты передал его в set_onclick? В этом случае, не удалит. Или ты не создавал элемент, а получил его при помощи get_element_by_id? В этом случае ты получишь ссылку на элемент, и будет удалена ссылка на элемент, а не элемент.
> попробуй одну и ту же функцию повесить на разные onclick - компилятор скажет что переменная уже заимствована.
Не скажет. Ты ведь можешь одну и ту же функцию использовать в rust'е штатно из многих мест? Можешь. Почему же нельзя передать эту функцию во много разных мест?
Если это глобальная функция, то правила работы с ней примерно такие же, как правила работы с глобальными const переменными. Если это замыкание... Ну, тут надо уметь работать с замыканиями. Надо открыть соответствующую главу rust book, и прочитать её вдумчиво. Можно ещё порыться в документации к std::sync::Mutex и std::refcell::RefCell, там AFAIR был где-то пример, как можно создавать _много_ замыканий работающих с одними и теми же объектами. Я думаю, это всё же было в Mutex, там вроде был цикл, который создавал тучу потоков, каждый из которых был замыканием, работающим с одними и теми же объектами -- Mutex тут был бы адекватнее, чем RefCell. Но, всё же, каждое замыкание было отдельным объектом, в том смысле, что для каждого создавалось собственное окружение, которое он захватывал в move-семантике. То есть, функция была одна, а замыкания разные.
Все эти сложности с Mutex, RefCell и Arc может и не нужны, если замыкание работает с const переменными, но помимо того, чтобы быть const, они должны ещё жить не на стеке. Либо статически, либо в куче. Но во втором случае возникнет вопрос "когда освобождать память", и поэтому тебе придётся использовать Arc, и делать clone этого Arc'а на каждое замыкание. Если же переменные живут статически, то тут вообще будет не замыкание, а заурядная функция, объявленная при помощи fn, и проблем возникнуть не должно.
> Не знаю как этом идти в hrml DOM
"Не знаю, как с этим идти в html DOM"? Ты это хотел сказать?
Раст ведь очень много чего позволяет. Чего он не позволяет делать, так это глупостей: если ты меняешь переменную из разных мест асинхронно, то будь добр, сделай это так, чтобы не создавать data race.
Чтобы знать как написать safe API к html DOM, надо учиться. Взять и написать что-нибудь на расте. Надо пойти на github, и почитать чужой код. Надо не стесняться нажимать на кнопочку src, рядом с описанием функций в документации: если ты не понимаешь, как такую функцию написать на rust'е, сходи и посмотри. Rust -- это не жабаскрипт, в нём всё же полезно понимать, что там происходит под капотом. Почитай rustonomicon -- там очень подробно обсасывается грань между safe и unsafe, объясняется когда нужен unsafe, и как им пользоваться так, чтобы создавать safe API, и там же объясняется мотивация почему именно так сделано, а не как-то иначе. Можешь ещё поискать в гугле по слова rust+"too many linked lists", это замечательный гайд, который долго обсирает linked list как структуру данных, мотивируя отказ от linked lists в стандартной библиотеке rust'а, а потом создаёт эти linked list в различных вариантах, чтобы объяснить как это можно делать, если первая демотивирующая часть не отвращает от затеи. Демотиватор можно не читать, а вот всё остальное почитать полезно: LinkedList вынуждает решать множество проблем с data race, так что если ты осилишь LinkedList, то тебе никакое дерево DOM уже не будет страшно.
