doc: meta built-in names support

TODO

@@ -36,4 +36,3 @@ TODO:
 * review build process for testbed (i.e. tests first due to SDL)
 * use any for meta_custom_node
 * avoid copying meta_type/data/func nodes
-* doc for labels on meta elements

docs/md/meta.md

@@ -3,10 +3,11 @@
 # Table of Contents
 
 * [Introduction](#introduction)
-* [Names and identifiers](#names-and-identifiers)
+* [Identifiers](#identifiers)
 * [Reflection in a nutshell](#reflection-in-a-nutshell)
   * [Any to the rescue](#any-to-the-rescue)
   * [Enjoy the runtime](#enjoy-the-runtime)
+    * [Tell me your name](#tell-me-your-name)
   * [Container support](#container-support)
   * [Pointer-like types](#pointer-like-types)
   * [Template information](#template-information)
@@ -33,19 +34,19 @@ reflection system for `EnTT`. Maybe I did not do better than others or maybe
 yes, time will tell me, but at least I can model this tool around the library to
 which it belongs and not the opposite.
 
-# Names and identifiers
+# Identifiers
 
 The meta system does not force users to rely on the tools provided by the
-library when it comes to working with names and identifiers. It does this by
-offering an API that works with opaque identifiers that may or may not be
-generated by means of a hashed string.<br/>
+library when it comes to working with identifiers. It does this by offering an
+API that works with integral values that may or may not be generated by means of
+a hashed string.<br/>
 This means that users can assign any type of identifier to the meta objects, as
 long as they are numeric. It does not matter if they are generated at runtime,
 at compile-time or with custom functions.
 
-That being said, the examples in the following sections are all based on the
-`hashed_string` class as provided by this library. Therefore, where an
-identifier is required, it is likely that a user defined literal is used as
+That being said, some of the examples in the following sections are based on the
+`hashed_string` class as provided by this library. Therefore, where an integral
+identifier is provided, it is likely that a user defined literal is used as
 follows:
 
 ```cpp
@@ -82,8 +83,8 @@ However, it is also possible to assign custom identifiers to meta types:
 entt::meta_factory<my_type>{}.type("reflected_type"_hs);
 ```
 
-Identifiers are used to _retrieve_ meta types at runtime by _name_ other than by
-type.<br/>
+Identifiers are used instead of the type to _retrieve_ meta types at runtime, if
+necessary.<br/>
 However, users can be interested in adding features to a reflected type so that
 the reflection system can use it correctly under the hood, while they do not
 want to also make the type _searchable_. In this case, it is sufficient not to
@@ -127,7 +128,7 @@ generally used to create the following:
   ```
 
   The `data` function requires the identifier to use for the meta data member.
-  Users can then access it by _name_ at runtime.<br/>
+  This is then used for runtime access.<br/>
   Data members are also defined by means of a setter and getter pair. These are
   either free functions, class members or a mix of them. This approach is also
   convenient to create read-only properties from a non-const data member:
@@ -149,7 +150,7 @@ generally used to create the following:
   ```
 
   The `func` function requires the identifier to use for the meta data function.
-  Users can then access it by _name_ at runtime.<br/>
+  This is then used for runtime access.<br/>
   Overloading of meta functions is supported. Overloaded functions are resolved
   at runtime by the reflection system according to the types of the arguments.
 
@@ -240,7 +241,7 @@ In all cases, the returned value is an instance of `meta_type` (possibly with
 its id). These objects offer an API to know their _runtime identifiers_, to
 iterate all the meta objects associated with them and even to build instances of
 the underlying type.<br/>
-Meta data members and functions are accessed by name:
+Meta data members and functions are accessed by means of their identifiers:
 
 * Meta data members:
 
@@ -305,6 +306,42 @@ internally by `meta_any` and the meta objects when needed.
 Meta types and meta objects in general contain much more than what was said.
 Refer to the inline documentation for further details.
 
+### Tell me your name
+
+For meta types, data and functions, users can also provide custom _names_:
+
+```cpp
+entt::meta_factory<my_type>{}
+    .type("type"_hs, "my_type")
+    .data<&variable>("data"_hs, "variable")
+    .func<&function>("func"_hs, "function");
+```
+
+The _label_ provided **should** be a string literal. The library does not make
+copies. It is up to the user to guarantee the lifetime of the name itself.<br/>
+String identifiers are returned from the meta objects via the `name` function:
+
+```cpp
+const char *name = entt::resolve<my_type>().name();
+```
+
+Since most of the time there is no need to differentiate the _name_ from the
+numeric identifier associated with a meta object, `EnTT` also offers a more
+compact version of these functions:
+
+```cpp
+entt::meta_factory<my_type>{}
+    .type("my_type")
+    .data<&variable>("variable")
+    .func<&function>("function");
+```
+
+Again, the name provided **should** be a string literal. The string is then used
+to generate a numeric identifier with the `hashed_string` class.<br/>
+Despite support for names, there are no string-based lookup functions available.
+That is, types (`resolve`) as well as data members (`data`) and function members
+(`func`) are only _searchable_ by numeric identifiers.
+
 ## Container support
 
 The runtime reflection system also supports containers of all types.<br/>