Struct restriction

[chris-rgr]

Is there any specific reason that components need to be structs? Is that Lex/LeoECS purely being opinionated or am I missing something? Arrays are guaranteed to have a linear layout, even for reference types. Is this due to the indirection via the ItemPool struct?

I know that in an ideal performance-oriented world we'd just have structs filled with value fields, but having to handle references to components via ref is a pain (and potentially prone to errors, because, you know, structs generally shouldn't be passed around as refs most of the time...). So unless I'm missing something, allowing reference types as components wouldn't necessarily negatively impact performance for pools/systems that only utilize structs, right? If so, why not open up the architecture a little and drop the struct enforcing?

[SinyavtsevIlya]

@chris-rgr Sorry for the late reply! Didn't notice your comment.

Is there any specific reason that components need to be structs?

There is a small performace boost on linier processing comparing to a class based components version.

Arrays are guaranteed to have a linear layout, even for reference types

They are. But this linear layout applies to the references themselves, while they pointing to a random place in memory. This leads to cache misses when processing large amounts of data.

(and potentially prone to errors, because, you know, structs generally shouldn't be passed around as refs most of the time...

This is a unusual for the first time, but you get used to it eventually.

The core of the framework is mostly based on leoecs-lite, i just hacked component indexes generation a bit. At the moment I have no plans to make class version.