On Thu, Oct 4, 2012 at 8:16 PM, Matt Calabrese <rivorus@gmail.com> wrote:
On Thu, Oct 4, 2012 at 5:25 PM, Dave Abrahams <dave@boostpro.com> 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