Boost logo

Boost :

Subject: Re: [boost] Boost.Generic, C++0x Concepts, and C++1y Concepts
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2012-10-04 23:16:54

On Thu, Oct 4, 2012 at 5:25 PM, Dave Abrahams <dave_at_[hidden]> wrote:

> I would not draw too many conclusions from the recent EWG proposals. It
> remains unclear to many of us that the "valid expressions" approach is
> technically or ergonomically feasible.

Yeah, this is sort of my conclusion. I really don't understand the move
away from pseudo-signatures, the lack of mention of archetypes, lack of
associated type deduction, etc. I think what I'm going to try to do is
finish Boost.Generic following N2914 along side of Lorenzo's N3351
implementation (and preferably start sharing backend implementation of some
things). At that point, perhaps we'll have two reasonable implementations
of the ideas presented in both and people will actually be able to
determine which proposal they feel is more suitable for standardization. It
also makes it easy to experiment with different library specifications as
well. Right now, I get the sense that some people definitely want concepts
in some form but don't necessarily have an understanding of all of the
nuances of the different approaches (let alone the larger capabilities),
making it difficult to make a sound judgment on the benefits and drawbacks
of each. If people have a chance to actually use both implementations,
especially developers of generic libraries, it will hopefully make the
debate at least a little less theoretical than it currently is.

> You should bring it to
> or
> .

Once I finish all of the explicit concept map changes and properly document
the library, I'll do that. Right now the tests, slides, and N2914 are the
only documentation.

> ? That seems to cover implicit (not explicit) concept maps:
> Implicit concept maps for refined concepts [concept.refine.maps]

It affects the implicit generation of concept maps of less-refined concepts
based on explicit concept maps of a more-refined concept -- in a world of
all auto concepts, none of this is comes into play (which is why
Boost.Generic works perfectly fine in all tested cases for concepts that
make even heavy use of refinement, as long as the concepts involved are
auto). The tricky part comes from coding the concept map look-up for
concept maps of less-refined concept in the case where someone provides a
concept map template for a more-refined concept. This is nontrivial since
it's entirely possible for, I.E., a more-refined concept to have more (or
less, or reordered) arguments than a concept that it refines, but the
less-refined concept still needs to be deducible from the template
arguments for the more-refined concept's concept map template; otherwise,
it would be impossible to match that template with the less-refined concept
(that was a mouthful). This type of situation is what's referred to in that
part of the standard that I linked. The trick I use in the end is to make
curious use of template aliasing along with function template overloads to
get the same type of deduction and pattern matching that is described in
the standard. It's a little bit trickier than that because the library
needs to keep track of the more refined concepts and concept maps in
compile-time mutable type lists that are updated every time a new concept
refinement or concept map is introduced in a translation unit. My
proof-of-concept on this works, but it's taking a few days to implement in

-Matt Calabrese

Boost list run by bdawes at, gregod at, cpdaniel at, john at