On Monday, January 31, 2011 13:25:16 spir wrote: > On 01/31/2011 08:32 PM, Jonathan M Davis wrote: > > At minimum, it needs to be smarter about user-defined types. The > > functions for a class or struct should not be grouped with free > > functions. They should be grouped with the type that they're in._That_, > > at least, should be automatable, > > Isn't that's what namespaces are for? A big advantage of OO-like coding (or > custom namespaces) for std modules. > > > but it wouldn't help any with std.algorithm, since it's full of free > > functions (though it would be a big improvement for std.datetime). > > See above. Why aren't many algorithms implemented in the modules defining > what they operate on? Sure, "free" algorithms precisely are meant ot be > generic. But in most cases there is, or could (should) be, a top-level > type. In particular, don't many algos work on ranges?
Classes and structs already group functions naturally, and that grouping needs to be evident in the generated ddoc pages. As for free functions, there's a huge difference between namespacing functions and grouping them in documentation. Namespacing was introduced in C++ to avoid name collisions. D uses modules as namespaces and also allows you to avoid name collisions. But that doesn't mean that there isn't value or necessity in grouping functions within a namespace or module. If there aren't all that many functions in a module, then you don't really need to group them, but when you get as many functions as you do in std.algorithm, it can definitely be useful. std.algorithm doesn't have problems with name collisions and doesn't need to be broken up, but it _is_ large enough that grouping some of its documentation would be useful. And simply grouping the links to the functions at the top would be a definite improvement. Regardless, it's a separate issue from namespacing. - Jonathan M Davis