How to check member function for being @disable?

[Uranuz via Digitalmars-d-learn]

On Tuesday, 13 September 2016 at 15:32:57 UTC, Jonathan M Davis 
wrote:
> 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

OK. Seems that there is nothing that I could do more about my 
example code.. So the best way to be sure if something is 
assignable property is to try assign to it and test whether it 
compiles. The question was because utill this moment I somehow 
was living without __traits(compiles..). Seems that my use cases 
just was not enough complicated... Thanks for the answers.

It could be good idea to have __traits( isDisable ... ) or 
something for it. I admit that not only '@disabled this();' 
regular methods could me marked @disable too..