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

Subject: Re: [boost] [functional] Interested in can_be_called<F, Sig> metafunction?
From: TONGARI (tongari95_at_[hidden])
Date: 2012-11-07 03:18:35

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.
But do you think member-function ptr fits in this context? e.g.

    has_call<void(X::*)(), void()>::type // mpl::true_

> 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.
Otherwise I have to follow the convention of the parent lib...