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?

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.

--
  Simen

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

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