Phobos classes member declaration order

[Jonathan M Davis]

> Is there any particular reason to declare class members in the middle of
> the class, *after* they are referenced many times? core.thread is an
> example.
> 
> This makes some difficulties to find where they are defined. Compiler
> doesn't care, but humans do :)
> 
> It would be so easy to search for "class X" and see all declarations
> instead of scrolling through pages of code looking for declarations, when
> search doesn't really helps - it find a lot of references first.
> 
> Or at least, if declaration would be before references, that would help a
> lot.

I believe that the two most common practices when declaring member variables 
is either to put them all at the top of the class declaration or all at the 
bottom. If they're private (as is usually the case), I much prefer to put them 
at the bottom.

In the case of core.thread, it looks like they were grouped based on what 
they're used for. Most of them still ended up towards the bottom in the 
private section, but there are two which are in the middle. They are, however, 
_public_ variables (and const __gshared to boot), so they're constants rather 
than being normal member variables. As such, it makes some sense to put them 
up with the public functions, and they're right next to the ones that they go 
with logically (the priority-related stuff). I'm not sure that that's how I 
would have laid it out, but I can see why it is the way that it is. I don't 
think that that is commonly done in the various classes in Phobos however. Of 
course, technically-speaking, core.thread is in druntime rather than Phobos, 
though I wouldn't think that that would have much to do with the class' layout 
other than the fact that it has far more version blocks than would be typical 
in a Phobos class (since it has to worry about OS-specific stuff far more than 
is typical with the functionality that Phobos covers).

- Jonathan M Davis