Lack of isPublic isPrivate isProtected compile time reflection features

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Jul 9 21:25:03 UTC 2018


On Monday, 9 July 2018 14:30:00 MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 07/09/2018 05:24 AM, Basile B. wrote:
> > By the way i forgot to mention something : it would not necessarily be a
> > good idea to put wrappers named isPrivate(), isPublic(), etc. in
> > std.traits because if the wrappers are instantiated in std.traits they
> > could not work correctly because the symbol that they would inspect
> > would not be accessible (since located elsewhere)... I'm not 100% sure
> > if __traits(getProtection) is affected but the problem described is
> > known as a problem when doing introspection with getMember for example.
>
> Isn't it pretty much standard in most languages for reflection to bypass
> access privileges? I seem to remember Java/C# being that way, but then,
> it's been a long time.

D currently does not. As I understand it, after the access level stuff was
last reworked so that private stuff didn't affect function overloading, it
was decided that we needed to change it so that it did allow code
introspection to examine private symbols (not necessarily to call anything -
I'm not sure that that was decided one way or the other), but AFAIK, no work
has actually been done towards fixing it. However, given that Andrei has
been working on a way to provide type information as a set of structs in
order to simplify and standardize accessing it, I expect that fixes for a
number of issues related to type introspection will finally end up getting
done, because his stuff won't work otherwise.

- Jonathan M Davis





More information about the Digitalmars-d mailing list