Privacy violation depending on who passes a compile-time argument?
Basile B. via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sun Aug 14 08:47:16 PDT 2016
On Sunday, 14 August 2016 at 12:03:28 UTC, rcorre wrote:
> Can someone help me understand why the first line is fine, but
> the second triggers a deprecation warning for access to a
> private variable?
>
> ---
> import std.traits;
> import s;
>
> pragma(msg, hasUDA!(S.getMember_i, attr)); // fine
> pragma(msg, hasUDA!(S.getMember!"i", attr)); // deprecated
>
> /++ in module 's'
> import std.traits;
>
> struct attr { }
>
> struct S {
> @attr private int i;
> alias getMember(string name) = Identity!(__traits(getMember,
> S, name));
> alias getMember_i = getMember!"i";
> }
> ++/
> ---
>
> getMember is not a mixin template, so it seems like
> __traits(getMember, S, "i") should be resolved within the 's'
> module in both cases.
No it's the opposite, only mixins gets the scope of the
instantiation's location.
> Why is passing the string "i" from another module a violation
> even when getMember_i is doing the same thing internally?
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.
More information about the Digitalmars-d-learn
mailing list