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