On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:
On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
I'm a bit sad to see that
https://issues.dlang.org/show_bug.cgi?id=15371 was completely
ignored to fix issue 15907. Another decision could have been
to break the visibility for the traits allMember, getMember,
derivedMember and getOverloads.
Well there was reasoning to choose that solution instead of the
other (https://github.com/dlang/dmd/pull/6078) and the fact
that private members aren't accessible (set/get) is a good
indication that nobody needs this.
As in needs private members in __traits(allMembers).
Adding an unsafe facility to access private members is a
separate problem, but please see the changelog for how to
achieve this already by mixing in templates.
Allowing access to private members has a lot of implications,
e.g. breaks lots of optimizations b/c you can't know who accesses
sth. It's also yet unclear what effect this has on @safe and we'd
not only have to modify visibility but remove the access checks
as well. This is clearly too much to just fix that problem w/
certain template instantiations, none of which should work on
private members atm.
Also you'd have to change a lot of existing code, or it would now
just operate on private members.
