Privacy violation depending on who passes a compile-time argument?

rcorre via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Aug 14 09:34:48 PDT 2016


On Sunday, 14 August 2016 at 15:47:16 UTC, Basile B. wrote:
> No it's the opposite, only mixins gets the scope of the 
> instantiation's location.

Right, if it were a mixin, it would get the scope of the 
instantiation (the main
module) and `i` would be inacessible.

Since it isn't a mixin, I would expect the scope to be in module 
s, where it
_can_ access `i`.

>
> Try to compile this:
>
> struct S
> {
>     private int i;
>     int j;
>     alias getMember(string name) = 
> Identity!(__traits(getMember, S, name));
>     alias getMember_i = getMember!"i";
>
>     unittest
>     {
>         pragma(msg, __traits(getProtection, S.getMember!"i")); 
> // private
>         pragma(msg, __traits(getProtection, S.getMember!"j")); 
> // public
>     }
> }
>
> You'll see that this is even not a matter of module. Actually 
> your "getMember" is not a member function, it's an alias to the 
> source, i.e the same symbol with the same protection.

Ok, so S.getMember!"i" is really the same as S.i, so I get why 
it's private. But
getMember_i is just an alias to that, so shouldn't it also be 
private?

It makes sense if you accept the following:

struct S {
     private int _i;
     alias i = i;
}

Which I used to accept without thinking about it, but now I'm 
wondering why that
works.



More information about the Digitalmars-d-learn mailing list