[Panzerschrek]

Is it memory safe? Can I cause use-after free, double-free, out-of-bounds access errors or something similar? What about race conditions?

In your DCMP examples you demonstrate how types can be composed from smaller components. How does it work under the hood? Is it possible to create an abstract container for Legs and store inside it any object having this component?

[zweiler1]

It is memory safe, use-after free, double-free, out-of-bounds access errors etc are all prevented by default. Of course there might be edge cases (bugs in the compiler) where a double free bug happens, but this should not be possible at the language level and then is a compiler bug (I fixed a lot of such bugs over the last few months). You can control them via specific compile flags to make it unsafe, but the default is all properly checked.

Race conditions should be prevented by design, but I haven't actually implemented multithreading at all yet, so I would rather not make any statements about it since it's not done.

I also posted the language on reddit and got quite a lot of feedback from it, and now I am redesigning many parts of it since it was a bit messy (static guarantees, that it basically has nothing to do with ECS any more etc).

I don't know what you exactly mean with an "abstract container". But yes the data `Legs` can be used across many different entity types, you can use and store that component in every entity type you would want to.

Under the hood it essentially is just owned composition, so the entity is just a tuple of pointers to its owned data components, nothing more.

[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).