Safe(r) variant of DefaultEcs

[Helco]

tl;dr I would like to propose a second variant of DefaultEcs that has some runtime warnings or error in place to help find common erroneous patterns.

Background

I seem to find all the trapdoors in the API, this time Entity.Dispose which in its documentation states the entity should not be used after calling, practically corrupting the world state if if ignored (components being attached to wrong entities).
It is debatable whether this constitutes a bug, which is why I did not create an issue for this. It is debatable as MSDN stats second calls should be ignored, but in such a high-performance library with documentation this requirement might be negligible.

But this only one of the occasions where I spend a lot of time debugging with and without the DefaultEcs source in order to find bugs in my application which stemmed from misuse in the API that is not (sometimes cannot) checked by the library.
The erroneous patterns were usually documented.

Proposition

It is clear that:

1. For best performance, additional runtime checks for safety are not wanted, especially in hot paths like per-frame operations.
2. Not every pattern can be detected by the library, e.g

ref var c = ref entityA.Get<Component>();
entityB.Add<Component>();
c = default; // might corrupt world state or be ignored

Therefore I would like to propose a second variant (thus a second NuGet package) which, controlled by a purely compile-time switch, has additional safety checks in place to prevent some misuse of the API. The recommendation would be for developers to use the "safer" variant during development and switch to the faster version for Release builds. Such a behavior can be configured in the project.

Detectable patterns

A non-exhaustive list of patterns (and possible checks) that could be checked would be:

• Multiple calls to Entity.Dispose
  with if (IsAlive && WorldId != 0) throw something;
• ComponentPool reallocation during Components-aided loops
  check for reference equality of the array using a reference to the ComponentPool or lambdas returning the proper references
• Modification of entity containers during loops
  Track container version by incrementing version number in IEntityContainer.Add/Remove and compare during loops in e.g. AEntitySetSystem

I have not (yet) looked at detectable patterns related to multi-threading (the usual bias towards the own projects and problems)
Additional exceptions could be added to improve debuggability, e.g. trying to retrieve a component that is not present on the specified entity throws an exception related to indices instead of stating something like "This entity does not have this component".

---

I am willing to help with an implementation of this but wanted to gauge acceptance of this idea for upstream and to discuss further potential checks to add.

[Doraku]

That's why I started the analyzer companion to detect the most obvious bad usages at compile time but some are harder to check and a more explicit runtime exception would go a long way to tell users when something has gone wrong without leaving them scratching their head.
Adding those checks at runtime in a specific setting is worth thinking about!

[nrader95]

I think there is a rather easy way of adding this, instead of making separate configuration, @Helco .
Add a static bool property somewhere (probably world) with #if DEBUG
And add ifs to that bool in any method that can backfire due to misuse, again with #if DEBUG block, with checks inside.

This way you can run debug version of ecs dll with almost no overhead (a single bool check is pretty much free, unless we turn it on and execute whats inside), and ability to turn checks on/off on demand, all without recompiling.

No need for extra configurations, or other complicated stuff.
something like this