Document zero-member support in the macro API reference

docs/mkdocs/docs/features/arbitrary_types.md already gained a note, but
the three api/macros pages are where the parameter contract is actually
specified and they still described member as a non-empty list.

State that the list may be empty on each page, and add a note showing
what the zero-member case generates: an empty JSON object for the plain
macros, and base-type-only serialization for the derived ones. Both notes
record that the WITH_NAMES variants do not support this.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

docs/mkdocs/docs/api/macros/nlohmann_define_derived_type.md

@@ -57,7 +57,8 @@ Summary:
 :   name of the base type (class, struct) `type` is derived from
 
 `member` (in)
-:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
+    list, which may also be empty
 
 ## Default definition
 
@@ -127,6 +128,20 @@ void to_json(BasicJsonType& j, const B& b) {
     - Macros 4, 5, and 6 have the same prerequisites of [NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE](nlohmann_define_type_non_intrusive.md).
     - Serialization/deserialization of base types must be defined.
 
+!!! info "Derived types without own members"
+
+    The member list may be empty. The macro then generates a `to_json`/`from_json` pair that only delegates to
+    the base type, so `type` serializes exactly like `base_type`:
+
+    ```cpp
+    struct derived : base
+    {
+        NLOHMANN_DEFINE_DERIVED_TYPE_INTRUSIVE(derived, base)
+    };
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     See Implementation limits for [NLOHMANN_DEFINE_TYPE_INTRUSIVE](nlohmann_define_type_intrusive.md) and

docs/mkdocs/docs/api/macros/nlohmann_define_type_intrusive.md

@@ -33,7 +33,8 @@ Summary:
 :   name of the type (class, struct) to serialize/deserialize
 
 `member` (in)
-:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
+    list, which may also be empty
 
 ## Default definition
 
@@ -58,6 +59,20 @@ See the examples below for the concrete generated code.
 
 [GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
 
+!!! info "Types without members"
+
+    The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
+    `#!json {}`, and a `from_json` that reads no members:
+
+    ```cpp
+    struct marker
+    {
+        NLOHMANN_DEFINE_TYPE_INTRUSIVE(marker)
+    };
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     - The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types

docs/mkdocs/docs/api/macros/nlohmann_define_type_non_intrusive.md

@@ -33,7 +33,8 @@ Summary:
 :   name of the type (class, struct) to serialize/deserialize
 
 `member` (in)
-:   name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a
+    comma-separated list, which may also be empty
 
 ## Default definition
 
@@ -59,6 +60,18 @@ See the examples below for the concrete generated code.
 
 [GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
 
+!!! info "Types without members"
+
+    The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
+    `#!json {}`, and a `from_json` that reads no members:
+
+    ```cpp
+    struct marker {};
+    NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(marker)
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     - The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types