ENH: Allow unnamed return values in Returns section of doc string

Developers usually only need the type of a return value
followed by a brief description. However, in some cases
providing a name for a return value can make the documentation
clearer. This enhancement changes the format of the Returns
section such that the type is required, and the name is
optional:

    Returns
    -------
    int
        Description of anonymous integer return value.
    x : str
        Description of string return value named `x`.

With this change, if a colon is not present, then the entire
line is interpreted as the return type. In all other cases,
the Returns section is interpreted according to the current
rules.

Consistent with the current format, if a colon is present, then
the text to the left of the colon is interpreted as the name;
and the text to the right of the colon is interpreted as the
type. This makes the proposed change backwards compatible with
existing documentation.

1 files changed, 19 insertions, 3 deletions

diff --git a/doc/HOWTO_DOCUMENT.rst.txt b/doc/HOWTO_DOCUMENT.rst.txt
index eeedd3204..13e9b2607 100644
--- a/doc/HOWTO_DOCUMENT.rst.txt
+++ b/doc/HOWTO_DOCUMENT.rst.txt
@@ -225,14 +225,30 @@ The sections of the docstring are:
 
 5. **Returns**
 
-   Explanation of the returned values and their types, of the same
-   format as **parameters**.
+   Explanation of the returned values and their types. Similar to the
+   **parameters** section, except the name of each return value is optional.
+   The type of each return value is always required::
+
+     Returns
+     -------
+     int
+         Description of anonymous integer return value.
+
+   If both the name and type are specified, the **returns** section takes the
+   same form as the **parameters** section::
+
+     Returns
+     -------
+     err_code : int
+         Non-zero value indicates error code, or zero on success.
+     err_msg : str or None
+         Human readable error message, or None on success.
 
 6. **Other parameters**
 
    An optional section used to describe infrequently used parameters.
    It should only be used if a function has a large number of keyword
-   prameters, to prevent cluttering the **parameters** section.
+   parameters, to prevent cluttering the **parameters** section.
 
 7. **Raises**