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

Ali Çehreli via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 30 15:24:12 PDT 2016


v2.071.2-b3 is bringing a change for this bug:

   https://issues.dlang.org/show_bug.cgi?id=15907

I don't agree with the current solution:

   http://dlang.org/changelog/2.071.2.html#traits-members-visibility

Modules should be able to use library templates without needing to mix 
them in first.

Do you think the solution in the change log usable? I don't think so 
because silently skipping my private members is an unexpected behavior 
that will cause bugs.

Further, do I understand the example right? Am I supposed to mixin the 
same template twice for two different types? The following code which 
adds another struct does not compile:

import std.stdio;
import std.traits;

enum UDA;
struct S
{
     @UDA int visible;
     @UDA private int invisible;
}

// only returns symbols visible from std.traits
static assert(getSymbolsByUDA!(S, UDA).length == 1);
// mixin the template instantiation, using a name to avoid namespace 
pollution
mixin getSymbolsByUDA!(S, UDA) symbols;
// as the template is instantiated in the current scope, it can see 
private members
static assert(symbols.getSymbolsByUDA.length == 2);

// --- The following is added by Ali: ---

struct S2 {
     @UDA int s2;
}

mixin getSymbolsByUDA!(S2, UDA) symbolsS2;    // COMPILATION ERROR:
// Error: mixin deneme.getSymbolsByUDA!(S2, UDA) TList isn't a template

static assert(symbolsS2.getSymbolsByUDA.length == 1);

void main() {
     foreach (i; 0 .. symbols.getSymbolsByUDA.length) {
         // ...
     }
}

I can't wrap my head around the fact that a library template called by 
my module cannot see my private members.

Ali


More information about the Digitalmars-d mailing list