Why 'getSymbolsByUDA' filters private members?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Tue May 29 02:46:03 UTC 2018

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

More information about the Digitalmars-d-learn mailing list