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