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

Martin Nowak via Digitalmars-d digitalmars-d at puremagic.com
Sat Sep 3 20:14:18 PDT 2016


On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei 
Alexandrescu wrote:
> On 9/3/16 7:57 PM, Jonathan M Davis via Digitalmars-d wrote:
>> 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.
>
> That... doesn't sound good. I wonder how such important changes 
> slip by Walter and myself unnoticed.

It didn't slip, but I wish Walter had at least stated his opinion 
on the PR before merging.

> My thinking is that the plebes should be able to access things 
> via the object.member syntax by obeying the usual visibility 
> rules. But __traits(allMembers, T) should be the reflection 
> backdoor that gives the savvy users total access, at the 
> obvious cost of an awkward syntax.

As explained several times here and in the announce thread, 
private members have never been accessible, other than 
introspecting attributes, and making them accessible comes with a 
performance cost and a fairly big language change.
So the real question is, why do we need introspection without 
access, and can we handle that few cases with mixin templates.
If we really need introspection of private members than we might 
need to go back to the drawing board and modify the visibility 
concept introduced with DIP22.


More information about the Digitalmars-d mailing list