Feature Request: group method overloads on a single API page

[SilentSin]

Unity's documentation puts all the overloads of a single method on the same page so you can easily compare their parameters. For example, GUI.Label.

Not needing a separate page for each overload might also make it possible to use member names as the page name instead of a GUID. I recently had one of those GUIDs change and break a couple of links from other pages (possibly due to removing the event keyword from the field?), which wouldn't have happened if I could just link to the member name.

[daveaglick]

I really like this idea. One question I have is how should we show documentation comments if they differ for each overload (which presumably they would, at least for different arguments). Maybe have a single page for the overloads but list each one in normal detail below? I guess we could also compare the comments for each method and argument and if they're identical across the overloads we could "collapse" the docs to a single page like Unity.

[SilentSin]

It seems the merged style is more of an exception than the rule in how they organise their documentation. Physics2D.Raycast for example just lists the details of 3 different overloads with their full descriptions one after the other, essentially keeping them separate but still all on one page.

Even just doing that so the Methods list on the class page doesn't need to include all the parameters in the Name column would be nice. I currently have quite a few methods with multiple overloads that have one line summaries, but end up taking up several lines because it tries to squeeze their parameters into the tiny Name column. For example:

That could all be a single line.

Trying to collapse them automatically whenever all parameters that share a name also have the same comment sounds like it would work reasonably well.

Are there any sort of tags or anything that could be included in the comments to tell Wyam how to manage the overloads without affecting the way Visual Studio displays the tooltip or anything else?

On a somewhat related note, I don't even bother documenting the parameters or return type on most of my methods since the summary already explains enough. So those functions end up looking like the image below where the Parameters and Return Type tables don't even show anything the Syntax hasn't already said. In such cases I think it would be best to simply skipped the tables entirely.