About Go, D module naming

[Jonathan M Davis]

On Friday, December 21, 2012 22:42:54 Walter Bright wrote:
> On 12/21/2012 6:55 PM, Timon Gehr wrote:
> > How it works within classes and structs only affects the exact contents of
> > error messages anyway, right? (not accessible vs. not defined) I'd
> > consider that a compiler implementation detail.
> 
> No, it affects the list of candidates for function overloading.

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?

- Jonathan M Davis