From https://dlang.org/spec/attribute.html#ProtectionAttribute

Protection does not participate in name lookup. In particular, if two symbols with the same name are in scope, and that name is used unqualified then the lookup will be ambiguous, even if one of the symbols is inaccessible due to protection. For example:

module A;
private class Foo {}
module B;
public class Foo {}
import A;
import B;

Foo f1; // error, could be either A.Foo or B.Foo
B.Foo f2; // ok


But Foo f1; // works ok now with 2.071.0

On Friday, 8 April 2016 at 13:28:15 UTC, Daniel Kozak wrote:
> From https://dlang.org/spec/attribute.html#ProtectionAttribute
>
> Protection does not participate in name lookup. In particular, if two symbols with the same name are in scope, and that name is used unqualified then the lookup will be ambiguous, even if one of the symbols is inaccessible due to protection. For example:
>
> module A;
> private class Foo {}
> module B;
> public class Foo {}
> import A;
> import B;
>
> Foo f1; // error, could be either A.Foo or B.Foo
> B.Foo f2; // ok
>
>
> But Foo f1; // works ok now with 2.071.0

The spec needs to be changed here (it was describing behaviour that was a long-standing bug).

On Friday, 8 April 2016 at 13:28:15 UTC, Daniel Kozak wrote:
> From https://dlang.org/spec/attribute.html#ProtectionAttribute
>
> Protection does not participate in name lookup. In particular, if two symbols with the same name are in scope, and that name is used unqualified then the lookup will be ambiguous, even if one of the symbols is inaccessible due to protection. For example:
>
> module A;
> private class Foo {}
> module B;
> public class Foo {}
> import A;
> import B;
>
> Foo f1; // error, could be either A.Foo or B.Foo
> B.Foo f2; // ok
>
>
> But Foo f1; // works ok now with 2.071.0

Btw:

import a : Foo;

Foo f1; // works OK even if Foo is private


Or even worse

import a : Foo;
import b;

Foo f1; // works OK use a.Foo

On Friday, 8 April 2016 at 13:31:38 UTC, Dicebot wrote:
> On Friday, 8 April 2016 at 13:28:15 UTC, Daniel Kozak wrote:
>> From https://dlang.org/spec/attribute.html#ProtectionAttribute
>>
>> Protection does not participate in name lookup. In particular, if two symbols with the same name are in scope, and that name is used unqualified then the lookup will be ambiguous, even if one of the symbols is inaccessible due to protection. For example:
>>
>> module A;
>> private class Foo {}
>> module B;
>> public class Foo {}
>> import A;
>> import B;
>>
>> Foo f1; // error, could be either A.Foo or B.Foo
>> B.Foo f2; // ok
>>
>>
>> But Foo f1; // works ok now with 2.071.0
>
> The spec needs to be changed here (it was describing behaviour that was a long-standing bug).

Yep. The previous behavior was bad because adding private symbols to a module should not break programs that import that module.

On 4/8/16 9:31 AM, Daniel Kozak wrote:
> On Friday, 8 April 2016 at 13:28:15 UTC, Daniel Kozak wrote:
>> From https://dlang.org/spec/attribute.html#ProtectionAttribute
>>
>> Protection does not participate in name lookup. In particular, if two
>> symbols with the same name are in scope, and that name is used
>> unqualified then the lookup will be ambiguous, even if one of the
>> symbols is inaccessible due to protection. For example:
>>
>> module A;
>> private class Foo {}
>> module B;
>> public class Foo {}
>> import A;
>> import B;
>>
>> Foo f1; // error, could be either A.Foo or B.Foo
>> B.Foo f2; // ok
>>
>>
>> But Foo f1; // works ok now with 2.071.0
>
> Btw:
>
> import a : Foo;
>
> Foo f1; // works OK even if Foo is private

Someone just filed this morning:

https://issues.dlang.org/show_bug.cgi?id=15896

> Or even worse
>
> import a : Foo;
> import b;
>
> Foo f1; // works OK use a.Foo

Note, import rules here say a.Foo is now a LOCAL symbol. It's like you did:

import a;
alias Foo = a.Foo;

This trumps any other imports. This is a long-standing rule that was not implemented properly in previous versions. You can get the old behavior back I think by doing -transition=import for dmd.

-Steve

On Friday, 8 April 2016 at 13:44:17 UTC, Steven Schveighoffer wrote:
> On 4/8/16 9:31 AM, Daniel Kozak wrote:
>> On Friday, 8 April 2016 at 13:28:15 UTC, Daniel Kozak wrote:
>>> [...]
>>
>> Btw:
>>
>> import a : Foo;
>>
>> Foo f1; // works OK even if Foo is private
>
> Someone just filed this morning:
>
> https://issues.dlang.org/show_bug.cgi?id=15896
>
>> Or even worse
>>
>> import a : Foo;
>> import b;
>>
>> Foo f1; // works OK use a.Foo
>
> Note, import rules here say a.Foo is now a LOCAL symbol. It's like you did:
>
> import a;
> alias Foo = a.Foo;
>
> This trumps any other imports. This is a long-standing rule that was not implemented properly in previous versions. You can get the old behavior back I think by doing -transition=import for dmd.
>
> -Steve

Even so, you shouldn't be able to make a local alias to private symbol from a different module.

On 4/8/16 2:03 PM, ZombineDev wrote:
> On Friday, 8 April 2016 at 13:44:17 UTC, Steven Schveighoffer wrote:
>> On 4/8/16 9:31 AM, Daniel Kozak wrote:

>>> Or even worse
>>>
>>> import a : Foo;
>>> import b;
>>>
>>> Foo f1; // works OK use a.Foo
>>
>> Note, import rules here say a.Foo is now a LOCAL symbol. It's like you
>> did:
>>
>> import a;
>> alias Foo = a.Foo;
>>
>> This trumps any other imports. This is a long-standing rule that was
>> not implemented properly in previous versions. You can get the old
>> behavior back I think by doing -transition=import for dmd.
>>
>
> Even so, you shouldn't be able to make a local alias to private symbol
> from a different module.

Sure, but the overloading behavior is expected is all I was saying. If a.Foo was not private, then the behavior above should be expected. The impression I get from the OP is that he thinks it's a further error.

-Steve

On Tuesday, 12 April 2016 at 11:42:08 UTC, Steven Schveighoffer wrote:
> On 4/8/16 2:03 PM, ZombineDev wrote:
>> On Friday, 8 April 2016 at 13:44:17 UTC, Steven Schveighoffer wrote:
>>> [...]
>
>>>[...]
>>
>> Even so, you shouldn't be able to make a local alias to private symbol
>> from a different module.
>
> Sure, but the overloading behavior is expected is all I was saying. If a.Foo was not private, then the behavior above should be expected. The impression I get from the OP is that he thinks it's a further error.
>
> -Steve

Ah ok, I see where you're coming from.