[Panzerschrek]

> It is memory safe

How? Do you have references/pointers? Are all objects except basic scalars heap-allocated and GC-tracked? Do you perform some clever compile-time analysis?

> I don't know what you exactly mean with an "abstract container"

I mean something like std::vector<Base> (from C++) able to store pointers to instances of derived classes.

> entity is just a tuple of pointers

It looks like having just a pointer to a Legs* component I can't access the whole object (having other components). Am I right?

[zweiler1]

All heap-allocated values like arrays are tracked at compile-time using a scoping system, when they go out of scope they are freed, similarly when variables are overwritten, assigned to etc "garbage" is detected by the system and at these points the freeing code is inserted. Every value can only be pointed to by one single value, so there are no "memory sharing semantics" (two variables pointing to the same memory) expect for memory managed by the automatic memory management system, DIMA, which is just a fancy per-type ARC-based incremental arena allocator, but these types (`data` and `entity`) are the only types managed by it which then means that these values can be pointed to by multiple variables since the RC is known, so it's safe.

Ah I see, at the moment there are no container types at all since generic types and thus monomorphization is not implemented yet. There is no inheritance in Flint, but you will be able to define type constraints on generic types to get something similar. This is part of the `0.5.0` release cycle but not implemented yet.

Yes, just from a ponter to Legs, you cannot access the entire entity, that's true. However, through polymorphism you are able to access an entity through a `func` modules view. (The `func` module is in the process of being split into two types, a polymorphic `interface` and a non-polymorphic type, I have no good name for it yet. I realized that it's very messy at the moment and definitely needs to be improved).