Re: [boost] Boost.Generic, C++0x Concepts, and C++1y Concepts

Subject: Re: [boost] Boost.Generic, C++0x Concepts, and C++1y Concepts
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2012-09-27 17:09:33

On Thu, Sep 27, 2012 at 4:00 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

> I'd probably be more interested in the part of the impl that expands
> the macro code to implement concepts, not necessarily the pp stuff.
>

Refer to boost/generic/concept.hpp line 253
BOOST_GENERIC_CONCEPT_IMPL_VALID_

It's probably hard to decipher since, as you probably realize, pretty much
everything needs to go into its own, separate metafunction and everything
needs to be expanded inside of template specialization argument lists in
order for SFINAE to take place, and all of the associated types of the
concept need to be template arguments to every single one of those
metafunctions for SFINAE to work with them as well. Also, on the macro
side, in order to reduce compile times, I avoid making multiple passes over
the top-level macro arguments and instead preprocess it all at once,
putting code that will eventually go into different locations into
different boost preprocessor sequence elements, and then I pull those out
individually at the end. This succeeded at greatly reducing compile-times,
but it makes the code harder to read.

> It might help to start by taking a look at
> contract/detail/preprocessor/traits/. Also, this is a possible syntax
> I had in mind for C++0x concept definitions:
>
>
> http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_0_4_1/doc/html/contract__/concepts.html#contract__.concepts.concept_definitions__not_implemented_

Looks great. I'll probably do most of that eventually, but I'd like to save
those changes for later, since what is in currently works and I'd rather
focus on new features first before I overhaul the interface.

I can't speak for this yet because I'm just now looking into C++1y concepts.
>

Given those that are associated with the paper, I assume that I may be
unique in this stance, though I could still be persuaded otherwise. My main
concerns are that the C++0x concepts very clearly matched with the notion
of archetypes (which I don't think N3351 even mentioned IIRC). When you
wrote a C++0x concept, it wasn't all that dissimilar from declaring a type
that models that concept, which, in my opinion, is a big advantage, and it
is also makes it fairly clear what archetypes you can except from that
concept. When I started Boost.Generic, I took the N3351 style approach but
was persuaded to adopt pseudo-signatures instead because of the drawbacks
of the ad-hoc expression-style approach (not just because it didn't match
up with C++0x concepts) so I'm having trouble going back now. As for
associated types, it seems like C++1y concepts are just relying on
C++98-style template type traits classes, with concepts only doing
verification on those type traits. To me this all just seems like a step
backward from what would have been C++0x concepts. I look at
iterator_traits as being a hack that came about because there is no direct
way to properly create concepts and concept maps with associated types in
C++98. Now that there is a chance to eliminate the need for it, aside from
legacy code, I'd rather not miss that opportunity, especially given that
C++0x concepts were very close to being a standard part of the language and
essentially removed the need for things such as iterator_traits (not to
mention that they removed the need for things like an explicit iterator
category, which these new concepts still have to rely on to some
extent). So perhaps this is simpler, but it seems to me like it's also less
functional, and that is something I don't agree with.

The one thing that I'm really a big fan of in N3351 is its considerable use
of axioms, but I just don't see any rationale for the drastic departure
from C++0x concepts.

-- 
-Matt Calabrese