About Go, D module naming

[Jonathan M Davis]

On Saturday, December 22, 2012 20:11:25 Rob T wrote:
> I had no idea this was going on. If "private" symbols are not
> really private then they shouldn't be called private because that
> is very misleading and can lead to subtle mistakes that will be
> difficult to understand and avoid.
> 
> When I've defined something to be private, I really expect it to
> be private to the outside, or at best a friend within the same
> module.

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.

In D, on the other hand, the problem is very much _not_ academic, because 
rather than having a global namespace, we have modules, and each of those 
modules has access levels for its symbols. We also have UFCS, which effectively 
makes it possible to add member functions to a class or struct without its 
permission, which isn't possible in C++. So, in D, it becomes possible to have 
functions which are inaccessible but which are quite visible and are 
considered in overload sets along with accessible functions. Because 
accessibility is determined _after_ the overloading is sorted out, simply 
adding a private function to your module or class can break existing code in 
other modules, because you've changed the overload set, causing there to be a 
name clash or resulting in a function which better matches the set of 
arguments in one of the calls to it but which then results in an error, 
because the new function is uncallable. Similarly, it makes private aliases 
useless, because it pollutes other modules just as much as public aliases do.

So, the situation is _very_ different from C++ even though the way that access 
levels are handled is essentially the same. And pretty much everyone calls 
foul as soon as they figure out that that's what's going on. Most people 
initially don't have any clue about it anymore than most people do with C++, 
because it's not how people think.  In C++, many people never figure it out. 
Only more knowledgeable C++ probgrammers are likely to know, because the 
difference is almost entirely academic. But in D, many programmers find out 
about it because they run into problems because of it, and I don't think that 
I've ever seen anyone other than Walter who thought that it was a good idea. 
But unfortunately, no one has been able to convince Walter of the need to 
change things yet.

A couple of related bug reports are:

http://d.puremagic.com/issues/show_bug.cgi?id=1238
http://d.puremagic.com/issues/show_bug.cgi?id=2991

I thought that there was one with a lengthier discussion on it, but that's all 
that I could find at the moment.

And here's another thread on the issue:

http://forum.dlang.org/post/mailman.266.1329071322.20196.digitalmars-
d at puremagic.com

- Jonathan M Davis