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

[Andrei Alexandrescu via Digitalmars-d]

On 9/4/16 11:09 AM, Martin Nowak wrote:
> On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote:
>> On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
>> Well let's come up with a better solution then.
>> Let's start by finding some proper use-cases that require
>> introspection on private members w/o having access to them.
>
> Still haven't heard really good use cases for the above, but the
> trade-offs for also allowing access to private members aren't that bad,
> thus it seems like the better path forward.
> See http://forum.dlang.org/post/ymkehalxcigswvltlfjj@forum.dlang.org

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