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

[Andrei Alexandrescu via Digitalmars-d]

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