Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)

Subject: Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-12-15 14:23:15

Alright, I'm updating the way concept maps are defined and I'd like some
feedback here before I go through the task of creating yet another
named-parameter macro. In designing Generic, I've gone in a slightly
different direction from what would have been C++0x concepts and concept
maps. In particular, instead of having "auto concepts", all concepts are by
default explicit, however, a programmer can create one or more "auto concept
maps" for a given concept. These "auto concept maps" act as concept maps
with optional conditions (SFINAE and metafunction conditions).

For instance, there has been concern in the C++ community about making
iterator concepts, not to mention many other concepts, auto. I side with the
explicit crowd and agree that most concepts should be be explicit, including
iterator concepts, however, given certain conditions, I believe that it is
acceptable for types that pass some kind of basic compile-time check to be
automatically mapped if the superficial requirements of the concept are met.
If it's not clear what I mean, here is an example:

//////////
BOOST_GENERIC_CONCEPT_MAP
( ( template ( (class) T ) )
, (ForwardIterator)( T )
, ( if ( check_if_T_uses_the_boost_forward_iterator_helper_base< T > ) )
)
(
// Empty implementation
)
//////////

In the above code we have an auto concept map for ForwardIterator that only
applies to types which inherit from forward_iterator_helper of
Boost.Operators. In addition to the explicitly specified "if" check, it will
also implicitly check via SFINAE all of the syntactic concept requirements.
The idea is that if a class uses the iterator helper base then it is likely
trying to be a forward iterator. While this is not entirely true 100% of the
time (a quick example is another intermediate base that uses this helper
base), it should be safe and useful in practice and is IMO a better
alternative to fully auto concepts, and it should alleviate the need for
programmers creating iterators to have to manually make empty concept maps
in many situations.

First, I'd like to get some feedback on this approach before I take the time
to fully implement it. Does the idea of "auto concept maps" as opposed to
"auto concepts" make sense? What problems may arise from this? One thing
that may initially appear to be a problem is that you can have two auto
concept maps with overlapping conditions, in which case the auto concept map
to use would be ambiguous. This problem can be alleviated by explicitly
specifying a non-auto concept map which would be preferred over the auto
maps. The rules for which concept maps get picked are the same as they are
for matching template specializations that have (optional) Enable_If style
conditions, as that's how everything is implemented underneath the hood, so
the method of disambiguation should be fairly familiar to C++ programmers.

If anyone sees any problems with this approach, please let me know, as it
will save me a lot of effort if there are any as-of-yet unforeseen
show-stopping problems.

-- 
-Matt Calabrese