On Tue, May 18, 2010 at 1:44 PM, Daniel James <dnljms@gmail.com> wrote:
On 18 May 2010 14:04, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
I think you are succesfully making the point that Boost.Contract syntax is no worse than that of Boost.Parameter; and since the latter made it into Boost, the syntax of Boost.Contract should be considered acceptable too.
Not at all, that's up to the reviewers to decide. We don't have any requirement to respect a precedent set by another review. There could be reasons why it's good for one library, but not another. It might also be the case that experience with Boost.Parameter suggests that it's a bad idea or just that the Boost.Parameter reviewers did a bad job.
Yes, of course. I agree 100% with all your points: 1) Reviewers should/will decide. 2) No requirement to be bounded by Boost.Parameter review results at all but just to learn from them. 3) Boost.Parameter experience in allowing macros to spoil function declarations should be taken into account critically. Plus (4) API usability and (5) trade off between benefits and syntax complexity should be considered as well -- for example, (4) Boost.Parameter syntax could be easier to program than Boost.Contract and/or (5) named parameters might be more beneficial than contracts. I honestly think the only point we were trying to make is that Boost.Contract parenthesized syntax should not be excluded *a priori* given that Boost.Parameter also spoils function declarations adding a comparable amount of syntactic complexity. I am sorry if I gave a different impression. -- Lorenzo