About Go, D module naming

[Jonathan M Davis]

On Friday, December 21, 2012 17:44:43 Walter Bright wrote:
> On 12/21/2012 12:44 AM, Timon Gehr wrote:
> > ... modulo the private symbol clash issue. For all I know it is
> > deliberate,
> > which is embarrassing. Other than obviously breaking modularity, it
> > severely restricts the usefulness of symbol disambiguation (which it
> > makes necessary when it should not be), because the disambiguating alias
> > may introduce more conflicts even if it is private, all over the code
> > base.
> 
> The reason it is that way is to avoid having it behave gratuitously
> differently than how visibility works within classes and structs.

??? I don't see anything here that would become different between user-defined 
types and modules.

All we're really asking for here is that inaccessible symbols not be put in 
overload sets. That way, you don't have problems where adding a private 
function to a module breaks existing code, because it clashes with a public 
symbol in another module when a third module imports both modules.  For 
instance, right now, private aliases are useless, because they're pretty much 
exactly the same as public aliases, because they introduce name clashes. There 
is _zero_ value as far as I can see in having private symbols in one module 
affect the symbols in another. private symbols should be implementation details 
and not affect the compilation of other modules.

I would expect it to be exactly the same with private member functions and 
UFCS. So, if a new private member function is added to a class or struct, and 
code was using a free function with UFCS with that type, the code wouldn't 
change behavior or otherwise break because of the conflicting function which 
was added. The private function _wouldn't_ conflict, because it's private.

So, I don't see anything different here about how private would be handled 
between free functions and structs/classes. It seems to me like it would be 
exactly the same rather than gratuitously different. And even if it _were_ 
somehow different, the current behavior makes it frustratingly easy to break 
code when simply changing the names of the private functions of a module - 
functions which are supposed to be implementation detalis, and I would think 
that the difference would be well worth it.

Given how much you abhor breaking users' code, putting inaccessible symbols in 
overload sets seems like a rather odd choice to me. I understand how it stems 
from C++, but C++ doesn't have module-level access modifiers, and it doesn't 
have UFCS. The result in D is far more fragile. It makes it way too easy to 
break other people's code.

- Jonathan M Davis