Benjamin Saunders

Queries are a good start, but we probably need random access as well, for example.

> This is pure speculation, but could this be cache effects of the increased working set due to the effect table? Surprisingly, that slowdown is for in-place/effect-free queries, for which...

A 10-fold difference is a lot to hand-wave, even so. Is that not sustained with `black_box` involved? Maybe a more computationally intensive benchmark would be interesting?

This would be useful for https://github.com/Ralith/hecs/pull/366, which presently must make two passes and perform a lot of redundant lookups to add/remove components to/from entities satisfying a query.

I'm not sure this the right place for it. We *want* the compiler to be able to aggressively optimize the interior of the loop; if it can't, that means the...

Given the utterly trivial implementation, I have no objection to providing this. In general, my stance on externally-implementable functionality has softened to including conveniences when they're sufficiently helpful and strongly...

Taking a slightly closer look at this, there's a wrinkle: skipping entities makes it harder to know in advance how many entities will be serialized. We could stop supplying a...

Sounds like a reasonable and straightforward API extension to me!

That's the theory. Unfortunately, as discussed in #20, the proposed interface runs afoul of rustc bugs regardless of implementation.

New idea: ```rust for mut entry in world.entries::().iter() { let (t, u) = entry.get(); // uniquely borrows entry // ... if should_destroy { entry.remove(); // consumes entry by value, invalidating...