inconsistent compile-time reflection

[Gor Gyolchanyan]

If this was brought up before, sorry for spamming.

I've been working on dynamic memory structuring mechanism (run-time
struct types) and I've felt the need to "import" the structure for a
dynamic struct type from a static (regular D) struct type.
When I was iterating over the members using __traits(allMembers,
StructType) it successfully went through all members, but when (in
case of a data field) I queried the type and address of the member
using __traits(getMember, structInstance_, memberName) it displayed an
error about the member not being defined. I figured out, that it was
because of the member being private. Therefore, I have 2 questions:

1. If the __traits(getMember, ...) won't return private members, why
does __traits(allMembers, ...) show them?
2. Why doesn't __traits(getMember, ...) return the private member in
the first place? One could easily hack around this limitation by
having the member analysis in a mixin template, so the analysis ends
up in the same module, hence giving access to the private members.
This doesn't provide any safety - only removes syntax sugar.

There are numerous cases, where private members need to be accessed
(serialization, for instance), wouldn't it be better to
__traits(getProtection, ...) in cases, where protection needs to be
respected?
After all, it's not in the D's philosophy to restrict people from
doing things "for their own good", like java does (that's why I hate
java). A back door for those, who know what they're doing is always
needed.

-- 
Bye,
Gor Gyolchanyan.