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

Subject: Re: [boost] Boost.Generic, C++0x Concepts, and C++1y Concepts
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-10-05 01:43:58

On Thu, Oct 4, 2012 at 8:16 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> 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).

Yes, this would be ideal to have two libs that implement concepts as
per N2914 adn N3351 so the std people can see impl of both ideas and
decide for the best when/if it comes to adopting concepts (and
hopefully also pre/post/inv) into the C++ standard. To this, the
syntax of the concept macros (Generic-like, Concept-like, more or less
extra parenthesis, etc) is essentially irrelevant as the main purpose
is to implement the concept design of N2914 and N3351 irregardless of
the syntax used by the lib to implement such a design.

All of that said, I don't have a lot of time to work on implementing
N3351 as my priorities are (1) get Boost.Contract into a release, (2)
reduce Boost.Contract compilation times, and (3) implement N3351
concepts (only last priority). However, I'd like to have an idea on
how to do (3) before I put it off to do (1) and (2) to see if there's
any major road block that could require Boost.Contract design changes.

> 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.

Thanks,
--Lorenzo