On Tuesday, September 13, 2016 04:58:38 Uranuz via Digitalmars-d-learn wrote: > In my code I iterate in CT over class methods marked as @property > and I have a probleme that one of methods is @disable. So I just > want to skip @disable members. I found possible solution, but > it's interesting to we if we have more clear and obvious way to > test for @disable without using __traits( compile ) for it? > @disable "looks" like attribute but seems that I cant't get it > through __traits( getAttributes ) or __traits( > getFunctionAttributes ). Maybe we could add something to test for > @disable if it's not already exists?
I really don't think that it's going to scale properly to check whether something is marked with @disable. The problem is that it propagates. For instance, if a struct has a member variable that has default initialization disabled via @disable this(); then that struct effectively has @disable this(); too even though it doesn't have it explicitly. So, ultimately what needs to be tested for is the behavior and not the presence of @disable, and that means testing with __traits(compiles, ...). And I would point out that most traits test via __traits(compiles, ...) or is(typeof(...)) rather than checking for something like an attribute. So, if don't like using __traits(compiles, ...) in metaprogramming, your going to get frustrated quickly. A large portion of the time, it's exactly the solution to the problem. - Jonathan M Davis
