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

[Johannes Pfau via Digitalmars-d]

Am Sun, 4 Sep 2016 14:54:33 +0200
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 9/4/16 2:37 PM, David Nadlinger wrote:
> > On Sunday, 4 September 2016 at 12:33:07 UTC, Andrei Alexandrescu
> > wrote:  
> >> Thanks for answering. Yes, we really need introspection of private
> >> members. One way or another we need to support that.  
> >
> > Do we, though? It's easy to state a general claim like this, but I
> > find it hard to actually justify.  
> 
> Static introspection is by far the most powerful feature of D. The
> last thing to do with it is hamstring it with nonsense like
> private :o).
> 
> Quoting elsethread:
> 
> > There are a few cases I can think of:
> >
> > * Serialization and deserialization, shallow and deep. These would
> > need access to the object layout, and possibly field names too (for
> > cross-checking and versioning purposes).
> >
> > * Binary saving, loading, and fixup (a subset of
> > serialization/deserialization) - that thing when you copy raw
> > memory to a file and then load it raw and fix pointers up.
> >
> > * Memory management and garbage collection: access to field types
> > allows efficient generic tracing.
> >
> > * Database interfacing, automated binding, object-relational
> > mapping, etc. It stands to reason that field names would be needed
> > and fields would be private, yet the database loader does have
> > access to them.
> >
> > Of course the more important applications are those I can't yet
> > imagine. The way I see it introspection must have full power and
> > unfettered access. So definitely it must be able to pass through
> > regular protection.  
> 
> 
> Andrei

All these examples need access to private data fields only.
Most performance optimizations are only possible for private functions
anyway. So is there a use case to access/call private functions?