On Tuesday, 29 May 2018 at 02:46:03 UTC, Jonathan M Davis wrote:
On Monday, May 28, 2018 05:43:23 Simen Kjærås via
Digitalmars-d-learn wrote:
On Sunday, 27 May 2018 at 17:42:15 UTC, Sobaya wrote:
> I'd like to get symbols that have an UDA.
>
> But when the member is private, it is not obtained.
>
> And I found a comment saying "Filtering inaccessible
> members" in the source.
>
> Why is it necessary to filter out private members?
Since the members are private, they're not visible to code in
other modules. getSymbolsByUDA is in std.traits, which is
another module, so code in it can't interact with the private
members.
There is definitely an argument to be made for allowing
reflection access to private members from other modules, but
the buck has to stop somewhere, and this is a complex problem.
If 'private' is to respected at all, clearly we can't have a
different module call our private methods, or read our private
fields. That means something as simple as a wrapper around a
function can't work.
The symbols are visible. They're just not accessible. As I
understand it, it's already been agreed that it should be
possible to look at them with introspection and get stuff like
UDAs from them. It's just that the implementation hasn't caught
up yet. So, right now, if you try to introspect on a private
symbol in another module (even if you don't try to actually use
it for anything), you get a compiler error, and that really
does need to be fixed. Actually using any such symbols should
continue to be illegal though. getSymbolsByUDA is an area where
there's been a lot of discussion on this, because it keeps
biting folks.
- Jonathan M Davis
The idea [1] was rather to remove the protection when using
__traits(allMembers|getMembers|...) and let people decide if they
follow the language rules or not using
__traits(getProtection,...) in their reflection code.
Problem is that the current way it works can lead to unfair
situations where self- introspection fails because the helper
template used to make the introspection is located in another
module. On the other hand if you copy the helper template where
it has to be used, the errors disappear.
[1] https://github.com/dlang/DIPs/pull/39