I vote NO for the inclusion of the contract library in Boost. I do agree that the work done is really interresting, but i don't think that using MACROS are the way to add this functionnality. Here are some thoughts why i think it should not be accepted: - i don't think that concepts should be part of the library. concepts and contract programming should not be mixed, they do not adress the same problem, they have not the same scope. The first is used at execution time, the other at compile time. - langage extensions, c+11 syntax, can't be really used, thus limiting the real benefit of this design. - compiler syntax error can be more cryptic to analyse with macro encapsulation. * What is your evaluation of the design? Despite the fact that i do not agree with the design taken to implement contract programming, i have to say that this library has some good macro design. A really nice job. * What is your evaluation of the implementation? i 'm not found of macros... so i can't comment on that. * What is your evaluation of the documentation? A really good job was done. * What is your evaluation of the potential usefulness of the library? A contract programming library could benefit boost. But i don't think that this library could be really used in production software industry beacause of it's use of macros. * Did you try to use the library? With what compiler? Did you have any problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I only took the time to read the documentation. * Are you knowledgeable about the problem domain? I still use eiffel contract programming, so i think i'm a knowledgeable user of contract programming.