Re: [boost] [TypeTraits] propose new callable-type call traits

Subject: Re: [boost] [TypeTraits] propose new callable-type call traits
From: TONGARI J (tongari95_at_[hidden])
Date: 2014-01-12 03:17:23

2014/1/12 Hui Li <hui.li_at_[hidden]>

> Has is_callable_with_args made into boost somewhere? Or is there a plan to
> make it into boost? Would like to know the status since the link is a few
> years old.
>
> It appears all 3 versions we have here follow 2 different approaches, and
> are different in terms of how an ambiguous call is handled.
>
> (1) compute and compare sizeof(<function call expression>) in some form
> This includes Eric Niebler's is_callable_with_args, and boost::has_call in
> c++03/98.
> In this approach, an ambiguous call would result in a compiler error
> within the traits class.
>
> (2) decltype(<function call expression>) in SFINAE context
> This includes my has_valid_call, and boost::has_call in c++11.
> In this approach, an ambiguous call would merely get the trait class
> evaluated to a false-type.
>
> Whether we want to distinguish non-viable and ambiguous calls or not, i
> think boost::has_call should behave the same in c++03/98 and in c++11. The
> current version does not, which can be surprising to users.
>

You may be right on providing the consistent behavior, but I don't know if
it'd be an oversight to add this restriction to C++11.

I no longer have a real world application where distinguishing a non-viable
> call and ambiguous call is absolutely necessary (for my use case, i'm going
> to switch to the sizeof approach to get the compile error for ambiguous
> calls).
>

Most of my usage will turn into error eventually no matter it's ambiguous
or non-viable, so it's non-issue to me thus far.

> However, I do think it's worth exposing to programmers as much information
> as possible of whatever the compiler knows. Since the compiler can
> distinguish a non-viable call and an ambiguous call, the programmers should
> be able to do that too,
> so that they have more control. that's one of the reason that we have
> metaprogramming, isn't it? :)
>

Anyway, feel free to propose those to Boost, and don't hesitate to pick up
the code/doc/test ready on my github if appropriate.
I'd like to see this functionality goes into Boost :)