(Was: On 80 columns should (not) be enough for everyone)

[Jonathan M Davis]

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