http://d.puremagic.com/issues/show_bug.cgi?id=10258
--- Comment #7 from Andrej Mitrovic <[email protected]> 2013-07-19 14:08:55 PDT --- (In reply to comment #5) > I think hasAccess traits would be completely redundant feature. This isn't a good workaround for two reasons: 1. It is not clear enough what is being done (same as JMD's argument) 2. __traits(compiles) silences all compiler errors. #2 is the most important reason. Here's an example: ----- struct S { int a; } void main() { static if (__traits(compiles, __traits(getMember, T, "a"))) { pragma(msg, "Can access a!"); } } ----- This will not print anything, because the aggregate type is wrong (it doesn't even exist!). It should have been 'S', not 'T', but __traits(compiles) has gagged the error message. Tracking down bugs like these are hard when there are no error messages. If instead we had a trait, the above would become: ----- static if (__traits(hasAccess, __traits(getMember, T, "b"))) ----- And the error message is clear: > Error: undefined identifier T, did you mean struct S? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
