diff --git a/docs/entity.md b/docs/entity.md
index b1e692617..6c613ed74 100644
--- a/docs/entity.md
+++ b/docs/entity.md
@@ -1178,7 +1178,7 @@ Similarly, the `each` member functions will propagate constness to the type of
the components returned during iterations:
```cpp
-view.each([](const auto entity, position &pos, const velocity &vel) {
+view.each([](auto entity, position &pos, const velocity &vel) {
// ...
});
```
@@ -1241,9 +1241,24 @@ during iterations.
iterations. For all the other entities, destroying them or removing their
components isn't allowed and can result in undefined behavior.
-Iterators are invalidated and the behavior is undefined if an entity is modified
-or destroyed and it's not the one currently returned by the iterator nor a newly
-created one.
+In these cases, iterators aren't invalidated. To be clear, it doesn't mean that
+also references will continue to be valid. Consider the following example:
+
+```cpp
+registry.view([&](auto entity, auto &pos) {
+ registry.assign(registry.create(), 0., 0.);
+ position.x = 0.; // warning: dangling pointer
+});
+```
+
+The `each` member function won't break (because iterators aren't invalidated)
+but there are no guarantees on references. Use a common range-for loop and get
+components directly from the view or move the creation of components at the end
+of the function to avoid dangling pointers.
+
+Iterators are invalidated instead and the behavior is undefined if an entity is
+modified or destroyed and it's not the one currently returned by the iterator
+nor a newly created one.
To work around it, possible approaches are:
* Store aside the entities and the components to be removed and perform the