Barend wrote:
Furthermore, you mention: "concept checking boilerplate around bool return type goes here". We've encountered problems with the concept checking on return types. The combination of BCCL and overloads based on SFINAE gives compiler problems here. We therefore use BOOST_CONCEPT_REQUIRES instead of _ASSERT in such cases.
What compiler problems specifically? I don't use BCCL for concept checking, and should have said SFINAE meta-programming boilerplate instead. By the way, I wrote my own true false types: struct gtl_yes{}; struct gtl_no{}; that I use for meta-programming logic, but I didn't quite feel right about it. Library authors often create their own such types, and this becomes a source of incompatibility. A user of two libraries that each define their own true/false types that wants to meta-program on top of both will find the task awkward. Having a boost header file that everyone is supposed to include that defines universal boost::true_type and boost::false_type seems like a good idea, and I've seen people push in that direction on this list for a while, but I don't think it is the best solution. It would be better to instead have a convention that void is false type and all other types are true. Similar to how zero is false and all non-zero integers are true. All meta-programming libraries that follow such a convention are compatible with each other without the need for shared dependency. I would then define my true false types thusly: struct gtl_yes{}; typedef void gtl_no; What do others who have defined their own true/false types or used those defined in boost think about such a convention? Is it backward compatible to change false_type definitions to typedef void to make such a convention feasible? Regard, Luke