Замыкание обобщенного типа в Rust

Все же думаю, что статика никакой роли на выделение переменных на стеке не влияет. Насколько я понимаю, 'static в расте означает то, что не только размер, но еще и расположение значения в памяти будет уже известно на этапе компиляции. В куче можно разместить что-либо, лишь положив это в Box, Rc либо какой-то другой смарт-указатель. Меня просто немного сбила с толку формулировка "static-типы", но вижу, что и в коде используется 'static в качетсве lifetime bound, что как бы намекает… Последний уточняющий вопрос: значит ли данное ограничение, что составить дерево из произвольного количества компонент на основе, например, пользовательского input'а с таким подходом будет невозможно?

Кстати, енамы со значениями так же будут иметь известный размер, так как по факту это обычные union-ы, размер которых принимает наибольшее значение размера его варианта (+ тег).

Вариант с вектором методов:

struct Component {
    node: Box<dyn Any>,
    model: Box<dyn Any>,
    methods: Vec<Box<dyn Any>>,
}

impl Component {
    fn new<Model: 'static + Debug>(node: Node<Model>, model: Model) -> Self {
        let use_model_a: fn(&Component) = |comp: &Component| {
            let model = comp.model.downcast_ref::<Model>().unwrap();
            println!("Model: {:?}", model);
            comp.node.downcast_ref::<Node<Model>>().unwrap().use_model();
        };

        let use_model_b: fn(&Component, i32) -> i32 = |comp: &Component, x: i32| {
            comp.model.downcast_ref::<Model>().unwrap();
            x
        };

        Self {
            node: Box::new(node),
            model: Box::new(model),
            methods: vec![Box::new(use_model_a), Box::new(use_model_b)],
        }
    }

    fn use_model_a(&self) {
        (self.methods[0]
            .downcast_ref::<fn(&Component)>()
            .unwrap()
        )(self)
    }

    fn use_model_b(&self, x: i32) -> i32 {
        (self.methods[1]
            .downcast_ref::<fn(&Component, i32) -> i32>()
            .unwrap()
        )(self, x)
    }
}

Запустить

Можно даже кастить функциональные указатели напрямую. Они одного размера, так что по идее с этим не должно быть проблем, хотя я на 100% не уверен в безопасности такого кода.

Процитирую проблему из статьи:

Такое решение подходит для тех случаев, когда исходный тип известен в месте работы с ним. Но что делать, если это не так? Что делать, если вызывающий код просто не знает об исходном типе объекта в месте его использования? Тогда нам нужно как-то запомнить исходный тип, взять его там, где он определен, и сохранить наряду с типажом-объектом dyn Any, чтобы потом последний привести к исходному типу в нужном месте.

Если было можно просто сохранить исходный тип объекта как обычное поле в самом объекте и потом скастовать к нему, то не потребовалось ничего изобретать. Если я правильно понял статью, конечно.

Енам, насколько я понимаю, не подходит, потому что нужно будет заранее знать все возможные исходные типы, чтобы их потом явно перебрать.

Представьте, что можно делать как-то так (прошу прощения для псевдо-С++):

class A { Type realType; };
class B : A
{

}

B b;
A * a = &b;
a.realType = typeof(b);

auto p = a as a.realType; // <<- auto выводит тип В

К сожалению, я плохо понимаю теорию языков программирования, поэтому не знаю, почему нельзя просто сделать тип Type или вроде того.

Вроде бы в Питоне так можно. И в Руби вроде есть класс Class. Хм. Может, к этому больше тяготеют языки с динамической типизацией, потому что там люди вынуждены тип в рантайме проверять.