[Review] Type Traits Extension by Frederic Bron - Review summary and decision

Hello all, Frederic Bron's type traits extension proposal review ended up last week. In so far, we received SEVEN reviews which are all voting YES for the inclusion of Type Traits extension in Boost. So the result is that the Type Traits Extension is ACCEPTED into Boost. Suggestions include: - some clean-up in the implementation like "Renam[ing] the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that." - Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic. - Frederic is OK to keep the detection of void as a valid return type by using some dont_check type as default. - small comprehensive example of some of the traits like a "maybe_print function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". [...] a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method." - The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. This topic is still hot and alive. An alternative to the naming scheme consensus was proposed in the form of alias of commonly used operator traits. This issue is I think beyond bikeshed-color argumentation and I think it is a good point if Frederic could step up and provide a definite and rationalized answer to this point. The current status is : * the namespace options is out casue the standard didnt choose this way; * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open * the std:: like naming seems limited as not all operators are there. Thanks to all reviewers and people participating to the discussions. Thanks to Frederic for his work.

- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto? I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_. Frédéric

- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
Yuk, to be honest, sorry! John.

Yuk, to be honest, sorry!
I found "an expression of disgust" in Cambridge Online. Is that what you mean? OK. Honestly, I wonder how to solve the desires of everybody on the naming topic. Kind regards, Frédéric

AMDG On 03/27/2011 11:24 AM, Frédéric Bron wrote:
Yuk, to be honest, sorry!
I found "an expression of disgust" in Cambridge Online. Is that what you mean? OK. Honestly, I wonder how to solve the desires of everybody on the naming topic.
You can't. In the end you're just going to have to make a decision and stick to it. However, I agree with John on this one. It doesn't read very naturally. In Christ, Steven Watanabe

2011/3/27 Frédéric Bron
Yuk, to be honest, sorry!
I found "an expression of disgust" in Cambridge Online. Is that what you mean? OK.
In respect of lingual appropriateness or "beauty" of naming constructions, I think we should listen to the advice of our native speakers.
Honestly, I wonder how to solve the desires of everybody on the naming topic.
Since your library extension is accepted unconditionally you have the freedom and also the duty to make a final choice yourself after considering all the arguments. Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

- Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic.
I have been able to treat the references better. I can now use the
real type provided to the trait without removing the reference
qualifier.
The counterpart is that, for example,
can_call_addition_assignment<int>::value is false which may seem
strange but:
- can_call_addition_assignment
participants (5)
-
Frédéric Bron
-
Joachim Faulhaber
-
Joel Falcou
-
John Maddock
-
Steven Watanabe