About Go, D module naming

[Jonathan M Davis]

On Sunday, December 23, 2012 23:34:41 Phil Lavoie wrote:
> In this case, I am convinced that there is no use of having the
> "no accessibility but visibility" particularity, because I cannot
> find any reason for it to stay like that (feature/exploit wise).
> On the other hand, I don't work on the compiler and I have no
> idea of what difficulties in would imply to change this. So the
> question I guess would be if changing its behaviour to make it
> predictable justifies the cost/work, for now (priority wise)?

If a function is truly hidden, then it wouldn't even be available for error 
messages and whatnot, and in some cases, it might be useful to give an error 
that a function is private rather than that it doesn't exist.

All we really need to do is make it so that inaccessible functions aren't put 
into overload sets. How big a change that is, I don't know, but it's not 
necessarily a small one, because right now, the access level is taken into 
account _after_ function overloading has been sorted out, and we'd have to 
change it so that it was taken into account before function overloading.

I wouldn't expect this to be a huge priority given some of what else needs to 
be done, but I really think that it should be fixed soon (prior to 2.062). The 
real trick is convincing Walter that it should be changed (though someone else 
like Kenji may end up actually implementing it).

- Jonathan M Davis