• Daniel Kozak (14/14) Apr 08 2016 From https://dlang.org/spec/attribute.html#ProtectionAttribute
• Dicebot (3/18) Apr 08 2016 The spec needs to be changed here (it was describing behaviour
• Vladimir Panteleev (3/26) Apr 08 2016 Yep. The previous behavior was bad because adding private symbols
• Daniel Kozak (8/23) Apr 08 2016 Btw:
• Steven Schveighoffer (10/37) Apr 08 2016 Someone just filed this morning:
• ZombineDev (4/30) Apr 08 2016 Even so, you shouldn't be able to make a local alias to private
• Steven Schveighoffer (5/26) Apr 12 2016 Sure, but the overloading behavior is expected is all I was saying. If
• ZombineDev (3/17) Apr 12 2016 Ah ok, I see where you're coming from.

Daniel Kozak <kozzi11 gmail.com> writes:

 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

Dicebot <public dicebot.lv> writes:

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).

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

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.

Daniel Kozak <kozzi11 gmail.com> writes:

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

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

ZombineDev <petar.p.kirov gmail.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

ZombineDev <petar.p.kirov gmail.com> writes:

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.