Documentation: function/method parameter lists

I was working to clarify the meaning of some parameters in someone else's project and suddenly realized there was no explicit way to document this aspect of the code.

My stop-gap attempt is to drop a bullet list into the long description, but it might be nice to have special handling around this.

/// Draws the given `Drawable` object to the screen.
///
/// * `ctx` - The `Context` this graphic will be rendered to.
/// * `drawable` - The `Drawable` to render.
/// * `quad` - A portion of the drawable to clip.
/// * `dest` - the position to draw the graphic expressed as a `Point`.
/// * `rotation` - orientation of the graphic in radians.
///
pub fn draw(ctx: &mut Context,
            drawable: &mut Drawable,
            quad: Rect,
            dest: Point,
            rotation: f32)
            -> GameResult<()> {
    drawable.draw(ctx, quad, dest, rotation)
}

In a language like Python, documenting parameters has greater importance since it provides hints to the expected types, but it still offers a good opportunity to discuss usage of, and how incoming values contribute to a result.

class Client(object):

    def __init__(self, url, api, mappers=None, default_chunk_size=200):
        """
        :param str url: full url to the atlas instance.
        :param str api: the api version to use.
        :param dict mappers: mapper classes to use for the element types
                             named in the keys.
        :param int default_chunk_size: sets the cursor limit for times when it
                                       is not being explicitly set by the
                                       caller.
        :raises atlas.exceptions.ServerCompatError: if server url is for an
                                                    incompatible server
                                                    version.
        """
        # ...

While having this info show up in the docs, this could also be leveraged in tooling (IDEs, etc).

Review the Rust and Python examples in the issue first; no repository files, tests, or entry points are named. Before implementation, define the documentation syntax and tooling behavior, then use that definition to establish what a completed change should demonstrate.