On Tuesday, September 13, 2016 08:28:10 Jonathan M Davis via Digitalmars-d- learn wrote: > 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.
What would make sense would be creating a trait to test for the @disabled functionality in queston - e.g. there could be an eponymous template named something like hasDefaultInitializer (though that name is a bit long) which indicated whether a type had @disabled this(); or not. Then you can use that trait in your code rather than using __traits(compiles, ...) all over the place. - Jonthan M Davis
