doc: updated doc for any/meta_any/poly

TODO

@@ -10,8 +10,8 @@ WIP:
 * isolate view iterator, unwrap iterators in registry ::remove/::erase/::destroy to use the faster solution for non-view iterators
 * compressed pair to exploit ebo in sparse set and the others
 * rename sparse_set::entity_type (and the others) to value_type
+* any/meta: remove dependency on <functional> (reference_wrapper, invoke)
 * scheduler, use any (or poly?) instead of unique_ptr
-* any and the like: remove constructor that accepts reference wrapper, allow only in-place T& and entt::make_any<T>(...)
 * resource, forward the id to the loader from the cache and if constexpr the call to load, update doc and describe customization points
 * make it possible to create views of the type `view<T, T>`, add get by index and such, allow to register custom pools by name with the registry
 * add user data to type_info

docs/md/core.md

@@ -280,21 +280,16 @@ an opaque container for const and non-const references:
 ```cpp
 int value = 42;
 
-// reference construction
-entt::any any{std::ref(value)};
-entt::any cany{std::cref(value)};
+entt::any any{std::in_place_type<int &>(value)};
+entt::any cany = entt::make_any<const int &>(value);
 
-// alias construction
-int value = 42;
-entt::any in_place{std::in_place_type<int &>, value};
-entt::any make_any = entt::make_any<int &>(value);
+any.emplace<const int &>(value);
 ```
 
-In other words, whenever `any` intercepts a `reference_wrapper` or is explicitly
-told that users want to construct an alias, it acts as a pointer to the original
-instance rather than making a copy of it or moving it internally. The contained
-object is never destroyed and users must ensure that its lifetime exceeds that
-of the container.<br/>
+In other words, whenever `any` is explicitly told to construct an _alias_, it
+acts as a pointer to the original instance rather than making a copy of it or
+moving it internally. The contained object is never destroyed and users must
+ensure that its lifetime exceeds that of the container.<br/>
 Similarly, it's possible to create non-owning copies of `any` from an existing
 object:
 

docs/md/meta.md

@@ -210,7 +210,7 @@ Among the few relevant differences, `meta_any` adds support for containers and
 pointer-like types (see the following sections for more details), while `any`
 does not.<br/>
 Similar to `any`, this class can also be used to create _aliases_ for unmanaged
-objects either upon construction using `std::ref` and `std::cref` or from an
+objects either upon construction using `std::in_place_type<T &>` or from an
 existing instance by means of the `as_ref` function. However, unlike `any`,
 `meta_any` treats an empty instance and one initialized with `void` differently:
 
@@ -386,7 +386,7 @@ object for a sequence container:
 
 ```cpp
 std::vector<int> vec{1, 2, 3};
-entt::meta_any any{std::ref(vec)};
+entt::meta_any any = std::make_meta_any<std::vector<int> &>(vec);
 
 if(any.type().is_sequence_container()) {
     if(auto view = any.as_sequence_container(); view) {

docs/md/poly.md

@@ -312,13 +312,13 @@ instance->draw();
 
 The `poly` class template offers a wide range of constructors, from the default
 one (which will return an uninitialized `poly` object) to the copy and move
-constructor, as well as the ability to create objects in-place.<br/>
-Among others, there is a constructor that allows users to wrap unmanaged objects
-in a `poly` instance (either const or non-const ones):
+constructors, as well as the ability to create objects in-place.<br/>
+Among others, there is also a constructor that allows users to wrap unmanaged
+objects in a `poly` instance (either const or non-const ones):
 
 ```cpp
 circle shape;
-drawable instance{std::ref(shape)};
+drawable instance{std::in_place_type<circle &>, shape};
 ```
 
 Similarly, it's possible to create non-owning copies of `poly` from an existing