Implication of emplace return value coupled with on_construct

[alexgeek]

Hi there,

Just had some thoughts on an issue that I've run into and wondering what people think.

The main issue is if I bind on_construct for a type then emplace it into the registry then during that callback I cannot remove the component.

Assuming emplace gets its origins from std::vector and the like, it wouldn't make sense for emplace to possibly have a side effect that removed the thing you were putting in. However since entt has callbacks involved there are some cases I can think of where it makes sense to remove the component that was just emplaced.

Example 1.

A spawn order component.

struct SpawnOrder {
   unsigned int count;
   int x;
   int y;
   entt::entity prefab;
}

In this example SpawnOrder is put into the registry and a callback generates a number of the given prefab at the location given. After which the data is no longer used but deleting it would cause emplace to fail.

Example 2.

A window.

struct Window {
  entt::hashed_wstring title;
  int width;
  int height;
  HWND hwnd
}

This is example is supposed to be similar to the likes of Kubernetes where you can provide some data and then missing parts will be corrected later. So if I were to emplace with L"Window", 800, 600, nullptr then the bound on_construct could use the partial information to then create the window and assign the hwnd member.

However if for example a parameter was incorrect (e.g. -600 instead of 600) then we would not be able to create the hwnd and assign it. Depending on the application there are different responses to this. Most people I guess would just assert/crash but other systems may want to just log an error and then remove the component. But again that would cause a crash anyway due to the return type of emplace.

This could be solved I guess by something like a nullable/optional return type of emplace.

What are people's thoughts though?

There are plenty of workarounds so this isn't a blocker for me.

Thanks,
Alex

[LiliumAtratum]

I tend to keep the contents of all callbacks as simple as possible. If it does something complex, you may inadvertely cause more and more callbacks and the whole program becomes hard to reason about, with many functions still hanging to be finished (that's why I don't trust standard OOP in certain domains)
So, what I would do, is to schedule the job within on_construct and process the job later, within a system (as in 'S' of an ECS), in the next update.

This job scheduling, can be as simple as push_back in a std::vector<entt::entity>, or you can use entt::observer constructed with an entt::collector for this. When you process such a job, you can then decide to destroy the component, or the whole entity if you wish.

[skypjack]

Actually, removing the component for which you received a notification is the only thing you can't do in a callback. You can sort pools, rmove other instances, create entities, create components, you can do literally everything but you can't remove that specific component. This is because it's also accessed and returned to the caller by the default pool.

Though, with the upstream version of EnTT and its full support for custom pools, you can replace the mixin used for signalling and define your own.
In this specific case, you can define a class that doesn't return the reference to the newly created object and use it for the types for which it matters. Note that the return type of emplace is decltype(auto), so it will work in all cases.
You can also pretend that all listeners return a boolean value to tell you if the element was removed or not, if it helps.
Custom pools give you the maximum flexibility in this sense.

[LiliumAtratum]

Actually, removing the component for which you received a notification is the only thing you can't do in a callback. You can sort pools, rmove other instances, create entities, create components, you can do literally everything but you can't remove that specific component. This is because it's also accessed and returned to the caller by the default pool.

I fear there is one more potential reason, although you have control over it - you do not know if in some other part of the program, there is no additional listener attached to the same component. If you destroy the component in one callback, I expect the other will hit UB of some kind. I am not sure if custom pools can solve that?
Obviously, if you can guarantee that no one will ever attach another listener, that's not an issue. But this is kind of a constraint that you cannot enforce at the compile level, and it is easy to miss or forget for a human programmer.

[skypjack]

I am not sure if custom pools can solve that?

Well, yes, if you define a mixin for enabling signals that accepts listeners with a function type bool(args...).
In this case, you can stop calling the listeners at any time. Moreover, keep in mind that EnTT doesn't pass the component to the listener at the moment, so you can still try_get it to avoid UB in case.
With custom pools, you can even force a single listener if you like and avoid the problem with multiple listeners as a whole. 🤷‍♂️

[alexgeek]

Thanks both, interesting points! 👍