В принципе, можно слегка упростить, сделав справедливое предположение, что повторяющихся имён не бывает, и тогда можно просто считать количество совпадений и выходить при достижении нужного количества, но имхо это ещё более уёбищно ))

не понимаю, зачем ты добавляешь их на строках 11 и 12?

Ну на самом деле я пользуюсь макросом для заполнения сета, но нужного крейта нет на плейграунде)

https://www.reddit.com/r/rust/comments/8i1z6d/entitycomponentsystem_architecture_for_ui_in_rust/

Кто вообще контрибъютил уже в репу раста?

похоже что задачу @mexus надо делать через это: https://docs.rs/im/10.2.0/im/

похоже что задачу @mexus надо делать через это: https://docs.rs/im/10.2.0/im/

ты так его задал.. я честно прочитал 4 раза

и теперь все его "честно прочитают" и опять забьют хуй

ну так никто тебе и не обязан задачки решать)

это не задачка а дилема выборы подхода архитектурно

А вообще ты пробовал свой вопрос кому-нибудь из авторов йоги задать? Мб подскажут решение

Я бы заменил Style на trait и реализовал 2 варианта: для йоги с ее структурой, чтобы не мешать ей работать, когда ты свои стили не пихаешь И второй -- свои стили, совместимые с Style Например трейтом StyleExt, к которому можно будет сдаункастить

Но очень маленькая и инфы нужной мало(

так?

Стоило только дать сниппет и нормально описать

В расте при каждом чище вызывается метод unwrap, этот метод юзается везде где ввод/вывод идет или в чем его смысл?

в расте принято кетчить это или тут философия что упало, то не должно жить?

Или юзай другие комбинаторы

в расте принято кетчить это или тут философия что упало, то не должно жить?

Нормальная обработка ошибок это возвращать из метода Result или Option, и при каждом вызове чего-то внутри использовать оператор "?" https://doc.rust-lang.org/book/second-edition/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-

сущность вопроса в том что у меня есть узлы йоги, структура Node, в ней можно хранить контекст и использовать по идее чистую йоговскую ноду как рут компонент дерева. А стили и контексты хранить внутри. У меня есть структура Style которая хранит в себе стили относительно классов, их же там меняет и сетапит. Но проблема в том что я не знаю как бы оформить красиво работу относительно узла йоги, все таки лайаут стили и апперанс стили разные. Лайаут стили вычисляются перед рендером, апперанс стили уже используются непосредственно для отрисовки. И поэтому у меня получается проблема вот такая: Я не могу просто взять из контекста style контекст на внешнее хранение, потому что тогда я не буду иметь доступа к ноде, и таким образом чтобы поменятб и аплайнуть стили, мне нужно или: - добавить методы дополнительные для Node (по грязному собственно реально форком себе йоги, ибо иначе внутри Node свои левые методы не добавить). Или - сделать обвязвку поверх ноды еще одной структурой, но тогда уже чистого дерева без доп обвязок не получится и кучу методов придется или транспортить, или копировать - делать копию ссылки и вставлять ее в контекст, но тогда получается какая то рекурсия, тобишь есть нода, в которой есть контекст, в котором есть нода, в которой есть контекст. Да и разыменование в таком случае по моему вызовет сегфолт.

И вот тут 3 стула, описаные выше. или делать метод для node с пробросом в контекст, или делать обвязку для ноды, или вставлять ссылку на ноду в style