About Go, D module naming

[Timon Gehr]

On 12/22/2012 09:21 AM, Walter Bright wrote:
> On 12/21/2012 8:38 PM, Jonathan M Davis wrote:
>>> 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.
>
> But they are in structs in classes (following the way C++ does it).
>

Actually this is not really what I am asking for. Maybe some terminology 
got mixed up?

A solution that is simple to understand and does not complicate the 
implementation a lot is the following:

Mandatory:

When resolving imported symbols, and there is a clash, ignore all 
private ones.

Optional:

Disallow overloading symbols with different accessibilities against each 
other.