About Go, D module naming

[Jonathan M Davis]

On Saturday, December 22, 2012 00:21:33 Walter Bright wrote:
> On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
> > But we _want_ that. The fact that inaccessible functions are even
> > considered in overload sets is horrible. That's precisely the problem. No
> > inaccessible functions should be in overload sets. Otherwise, simply
> > adding a private function to a module can break code elsewhere. I don't
> > see _any_ benefit in having inaccessible functions be in overload sets.
> > It's leaking implementation details outside of the scope that they're in
> > and breaking code elsewhere when changes are made. What do you think is
> > so desirable about having inaccessible functions in overload sets?
> 
> It's that way in C++ mainly so that it doesn't make the already complex
> overloading system even more so. And in 25 years of working with C++, I've
> never seen this make anyone's list of horrible things about C++.

C++ doesn't have module-level access modifiers or UFCS, so it's completely 
unaffected by this. In C++, you can't add functions to classes from the 
outside, so there's no concern about adding private functions to a class 
breaking code using that class. And you can't add a private function to a 
module, because there are neither modules nor private, free functions, so you 
aren't going to get breakage from adding a private function, because you can't 
add a private function. Either you add what is effectively a public function 
(though technically, it has no access modifier at all, since it's not part of a 
class) and risk breakage that way, or you create a function which is only in 
the cpp file. In D, on the other hand, you can add private functions to 
modules, and you don't normally have separate implementation files. So, the 
situation is completely different.

We created this problem by adding modules and making it so that that the 
functions in them have access levels. We have extra layers of encapsulation 
which just don't exist in C++, and we made them leaky, because we made it so 
that the private functions affect overload sets. So, the fac that C++ doesn't 
get these complaints is pretty much irrelevant. It doesn't have the features 
which make this a problem. And regardless of whether you get complaints about 
this in C++, there have been plenty of complaints around here about it in D.

Pretty much every time that this issue comes up, people are surprised by the 
fact that private symbols aren't hidden and pretty much no one wants them to 
be in overload sets. I think that you're the only one that I've seen post that 
they thought that the current behavior is a good idea (certainly, anyone who 
agrees with you is in the minority or is silent on the issue). What we 
currently have leaks implementation detalis and thus causes code breakage when 
the implementation is changed. It needs to be fixed.

- Jonathan M Davis