Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Jonathan M Davis via Digitalmars-d]

On Saturday, September 03, 2016 19:30:54 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 9/3/16 6:39 PM, Andrej Mitrovic via Digitalmars-d wrote:
> > On 9/3/16, Martin Nowak via Digitalmars-d <digitalmars-d at puremagic.com> 
wrote:
> >> On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote:
> >>> Ugh, it really should just give everything and have getMember
> >>> bypass it. That won't even break any code!
> >>
> >> It will, e.g. having getMember bypass protection means vibe.d
> >> would now serialize private members
> >
> > Then just add a check in vibe.d itself to avoid serializing private
> > members. You can still call getProtection on the symbol and skip
> > serializing it.
> >
> > Alternatively you can use UDAs so you can mark which fields should or
> > shouldn't be serializible. For example
> > https://github.com/msgpack/msgpack-d/blob/6046808c2e678e27cb2e2d9314241c36
> > 1a6fd0ae/src/msgpack/attribute.d#L21
> >
> > The bottom line is with restricting access to private symbols you have
> > no choice on the matter, while allowing access lets you specialize
> > whether to ignore the symbols or not.
>
> I didn't follow this closely, but clearly we need some means to access
> private members for introspection purposes. I hope we don't paint
> ourselves out of that corner. -- Andrei

Well, that certainly seems to be exactly what we're doing with the changes
that Ali is complaining about.

Previously __traits(allMembers, T) listed _all_ members, whereas now it wil
only list the ones that are accessible. The same for
__traits(derivedMembers, T). So, they'll still give you the private members
if you use them inside the module in question but not elsewhere.

I would have thought that the way to handle this would be to have them list
all members regardless of access level and then to have code check for the
access level if it cares. I would have thought that doing stuff like looking
at private symbols would be perfectly okay with no errors or deprecation
warnings and that it would just be _accessing_ the symbol that would be
disallowed and would require you to check for in code that used
introspection. But clearly, there must be something that I misunderstand
here, because that's not at all where this seems to be going.

I do get the feeling that too much of what we do with features like this is
ad-hoc without really designing things up front, and then we keep having to
tweak stuff as we go along in ways that aren't always particularly nice. And
this particular change seems to just be a reaction to problems that we ran
into with changing how imports work. And maybe it's the right choice, but
it sure doesn't seem like it.

- Jonathan M Davis