
Please always explicitly state in your review, whether you think the library should be accepted into Boost.
Yes, I think it should be accepted. I think it should be applied to lexical_cast as previously suggested, and if it is already included with the distribution for that purpose then making it a public interface does little harm while making a useful feature easily accessible for others to use, who would otherwise probably not bother or think to implement it.
- What is your evaluation of the design?
Initially I had some reservations about user-defined types being silently passed through. On second thought, the submission serves a very specific use, and limiting the valid input to the relevant arithmetic types would complicate the common use case with little benefit (it is unclear to me who would be better served by a more strict version.)
- What is your evaluation of the implementation?
Looks straightforward enough to me.
- What is your evaluation of the documentation?
Minimal but sufficient. The examples could use some tweaking - "int const" is always used as the example of a type that isn't promoted, while none of the promoted types are cv-qualified. I would rather see a plain "int" as non-promoted and "short const" -> "int const". This to demonstrate that cv-qualifiers are kept and to take a way a possible first-glance impression that const inhibits promotion.
- What is your evaluation of the potential usefulness of the library?
While of limited use, I believe the submission is valuable enough when it is usable - as a tool to reduce near-identical template instantiations - to justify inclusion in the type_traits library.
- Did you try to use the library? With what compiler? Did you have any problems?
I did not try to use it.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
A quick reading.
- Are you knowledgeable about the problem domain?
Reasonably so, but no expert. -- Daniel Wesslén

Daniel Wessl?n wrote:
Yes, I think it should be accepted. Thanks!
I think it should be applied to lexical_cast as previously suggested, and if it is already included with the distribution for that purpose then making it a public interface does little harm while making a useful feature easily accessible for others to use, who would otherwise probably not bother or think to implement it.
I'm going to post a suggestion about splitting lexical_cast into inlined public function and non-inline imlementation. Code size can be optimized even without applying integral_promotion.
- What is your evaluation of the documentation?
Minimal but sufficient. The examples could use some tweaking - "int const" is always used as the example of a type that isn't promoted, while none of the promoted types are cv-qualified. I would rather see a plain "int" as non-promoted and "short const" -> "int const". This to demonstrate that cv-qualifiers are kept and to take a way a possible first-glance impression that const inhibits promotion.
Good point. -- Alexander Nasonov
participants (2)
-
Alexander Nasonov
-
Daniel Wesslén