Structs on private section.

[Peter Alexander]

On 28/11/11 1:56 AM, deadalnix wrote:
> Le 28/11/2011 03:29, Alexey Veselovsky a écrit :
>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> D's private is different than some other languages (e.g. C++).
>>> 'private' provides access to the entire module.
>>>
>>> public: no access limitation
>>>
>>> private: access by the module
>>>
>>> package: access by the modules of the package
>>>
>>> protected: access by the inheriting classes
>>
>> But it works even if class Foo declarated in dufferent module.
>>
>> Also this code works:
>>
>> module a;
>>
>> private { struct S {int a;}}
>>
>> --------
>>
>> module b:
>> import a:
>>
>> void f() {S s; s.a=42;}
>
> So you now have discovered a bug.

A bug that has been known about for quite some time. I also created a 
pull request for a fix quite some time ago (June), but hasn't been 
pushed yet.

https://github.com/D-Programming-Language/dmd/pull/163
+
https://github.com/D-Programming-Language/druntime/pull/32

Unfortunately, the druntime changes are required due to issue 314. For 
example, with the private type fix, the following code would not compile:

---------------
module A;
struct Foo {}; // public
---------------
module B;
import A : Foo; // private selective import
---------------
module C;
import B;
import A;
Foo f; // error: B.Foo is private
---------------

Due to bug 314, the private import in module B causes Foo to become a 
private symbol of module B (rather than just importing it). When module 
C tries to use Foo, it first looks in module B, finding the private Foo 
and complains of access violation. It doesn't even look at the Foo in 
module A because access checks are done before overload resolution.

It's quite ugly that access checks are not considered in overload 
resolution because it means I can break user code by adding private 
symbols to my library. It won't be a silent break, but it will break 
nonetheless.