Re: [boost] [geometry] view_as concept casting

Subject: Re: [boost] [geometry] view_as concept casting
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-01-08 12:54:30

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