digitalmars.D.learn - Privacy violation depending on who passes a compile-time argument?
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. Why is passing the string "i" from another module a violation even when getMember_i is doing the same thing internally?
Aug 14 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.
Aug 14 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.
Aug 14 2016
On Sunday, 14 August 2016 at 16:34:48 UTC, rcorre wrote:On Sunday, 14 August 2016 at 15:47:16 UTC, Basile B. wrote: getMember_i is just an alias to that, so shouldn't it also be private?It is private: https://dpaste.dzfl.pl/83fcca84dde3, so the code you've posted in the first message could be a bug. The deprecation message also since this case has nothing to do with the transition period due to fix 314 (because your import is not selective).
Aug 14 2016
On Sunday, 14 August 2016 at 17:23:06 UTC, Basile B. wrote:On Sunday, 14 August 2016 at 16:34:48 UTC, rcorre wrote:One thing that will make things worth in the near future: Identity has the "package" protection on phobos master... https://github.com/dlang/phobos/blob/master/std/traits.d#L3224 previously it was public (it's still in the latest public beta, which i use).On Sunday, 14 August 2016 at 15:47:16 UTC, Basile B. wrote: getMember_i is just an alias to that, so shouldn't it also be private?It is private: https://dpaste.dzfl.pl/83fcca84dde3, so the code you've posted in the first message could be a bug. The deprecation message also since this case has nothing to do with the transition period due to fix 314 (because your import is not selective).
Aug 14 2016
On Sunday, 14 August 2016 at 17:23:06 UTC, Basile B. wrote:It is private: https://dpaste.dzfl.pl/83fcca84dde3, so the code you've posted in the first message could be a bug.Ah, you're correct. I'm not able to use either of them in runtime code.The deprecation message also since this case has nothing to do with the transition period due to fix 314 (because your import is not selective).Makes sense. I still wonder whether using something like getUDAs on a symbol exposed like this is valid, but I guess that hasn't been decided yet (https://github.com/dlang/phobos/pull/4724#issuecomment-239424693). Thanks for the insights!
Aug 14 2016