About Go, D module naming

[Rob T]

On Saturday, 22 December 2012 at 20:24:54 UTC, Jonathan M Davis 
wrote:
> They're private in the same way that they're private in C++. 
> They're
> inaccessible (i.e. can't be called), but they're not actually 
> hidden.
> Accessibility is only taken into account after overloading has 
> been sorted
> out. About the only place I'm aware of that this has any 
> practical effect in
> C++ is the fact that you can overload private functions (which 
> doesn't affect
> D, because private functions are never virtual in D). If they 
> were actually
> hidden, you couldn't. Everywhere else, the difference is 
> academic - primarily
> because only classes have any concept of access level.
[snip]

Thanks for taking the time to explain all that. The thread on the 
subject was a very interesting read and is a eye opener for me 
because I was mostly unaware of the issue. I'm happy I now know 
about it because it is something you have to know about otherwise 
you can run into difficult to understand problems.

So the problem is that "private" affects accessibility but does 
not affect visibility, and for various practical reasons most 
people will prefer it to affect (by limiting) visibility in a 
similar way as it does with accessibility.

Here's my thinking,

After we've installed the new development process, one of the 
things I am hoping we can work towards cleaning up, is the 
methods used for maintaining the D specification so that it is 
done in a much more efficient and accessible way.

Also the process for making decisions that affect the 
specification are not at all clear and seems to follow an ad-hoc 
method of endless discussions, often to no effect with poor 
retention, and that is a *lot* of wasted effort, so this is an 
area where a clear formalized process can have a lot of benefit 
for the community in terms of making it operate much more 
effectively given the limited resources.

Perhaps at some point after the next dmd version is released and 
stabilized, will be a good time to start working on implementing 
a process for managing the D specification, assuming of course we 
have enough consensus that this is a priority area in need of a 
solution. I sure hope most people think so!

--rt