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