Re: [boost] [functional] Interested in can_be_called<F, Sig> metafunction?

Subject: Re: [boost] [functional] Interested in can_be_called<F, Sig> metafunction?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-11-07 07:48:29

Le 07/11/12 09:18, TONGARI a écrit :
> 2012/11/7 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>
>> Le 07/11/12 06:18, TONGARI a écrit :
>>
>>   2012/11/7 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung_at_[hidden]>
>>>   On Tue, Nov 6, 2012 at 7:14 AM, TONGARI <tongari95_at_[hidden]> wrote:
>>>>   2012/11/6 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung_at_[hidden]>
>>>>>   Wouldn't this fit in Boost.TypeTraits, along side the other type traits
>>>>>> that introspect operators?
>>>>>>
>>>>>>   TypeTraits is also in my consideration, so I'm not against it.
>>>>> So would you suggest opening up a new Functional category in that?
>>>>>
>>>>>   Hmmm, well, maybe for documentation purposes, but I think that's the
>>>> only
>>>> place that Boost.TypeTraits has a notion of category...? I would think it
>>>> might be sufficient to group it with the operator type traits in the
>>>> documentation, though.
>>>>
>>>>   Well, though conceptually reasonable, but that'd seem exotic in all of
>>> the
>>> others named has_xxx...
>>>
>> Hi,
>>
>> Boost.TypeTraits has other traits as is_, ... What about is_callable_with?
>
> Hmmm, then I'd prefer a shorter "has_call" that'd fit in Operator Type
> Traits better.
has_ is related to something a class can have, while is_ can be applied 
to a class or a function.
> But do you think member-function ptr fits in this context? e.g.
>
>      has_call<void(X::*)(), void()>::type // mpl::true_
>
I don't think this fill you initial can_be_called. Do you?
>> I still prefer a new place if possible that I could have more control on
>>> it.
>>>
>>>
>>>   What kind of control do you want?
> To rule the doc style and include hierarchy, providing specific macros for
> compile/preprocess, for example.
Could you give some examples?
> Otherwise I have to follow the convention of the parent lib...
>
>
Could you say what is wrong following the parent lib?

Best,
Vicente