Boost logo

Boost :

Subject: [boost] [contract] future directions
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-09-18 00:01:45


Hello all,

Now that Boost.Contract has been accepted :D, I couldn't help but to
share where I see the library going next :)

First of all, I'll have to put Boost.Contract in one of the upcoming
Boost releases and I know that will be a lot of work! After that
however, I see the library pursuing the following future directions:

1) Reduce compilation times (both preprocessor and template
meta-programming optimizations) and possibly improve the
(preprocessor) syntax error messages. IMO the x30 compilation time is
the largest barrier for the lib adoption in production code, much more
so than the strange syntax. I think the 2nd largest barrier is the
cryptic syntax errors. The rationale is that you can learn a new
syntax especially if that's the only way to program C++ contracts
(assuming you actually need contracts) but if your projects takes 1
months instead of 1 day to compile and/or if the compiler errors don't
help you understand what you did wrong, you will find it very hard to
use the lib in large projects.

2) Support concepts similarly to Boost.Generic (N2081) and/or N3351.
This will probably be for C++11 only but many of us wish concepts were
part of C++11 and I think many people will favor a lib that supports
them (e.g., many people were interested in Boost.Generic).

3) Refactor the macro parsing code so the syntax can be extended by
the user. Ideally, this will result in something like Boost.Proto for
the preprocessor, maybe "Boost.PreprocessorProto" (even if the actual
API might be different and not necessarily equivalent to Boost.Proto
API because dealing with macro expansions instead of the template
expressions).

I don't know if any of the above can actually be achieved but if I'll
have time after the 1st Boost.Contract release I'll start working on
these projects in the listed order of priority.

Thanks.
--Lorenzo


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk