Re: [boost] [contract] syntax redesign

Subject: Re: [boost] [contract] syntax redesign
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-10-22 23:36:11

On Fri, Sep 2, 2011 at 3:14 PM, Dave Abrahams <dave_at_[hidden]> wrote:
> on Fri Sep 02 2011, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
>> (I still have to implement named parameter support (using
>> Boost.Parameter behind the scene) but that shouldn't be too hard. The
>> macros already parse the named parameter syntax using in/out/inout
>> "keywords".)
>
> I can't wait.

Hello all,

Here's how I am thinking to support named parameters within
Boost.Contract's syntax. Essentially, named (also template) parameters
are prefixed by the new preprocessor "keywords" in, out, or in out.

Sorry for the large amount of code but these are complex examples from
Boost.Parameter docs so you can directly compare this Boost.Contract
proposed syntax with the one of Boost.Parameter:
http://www.boost.org/doc/libs/1_47_0/libs/parameter/doc/html/index.html

namespace graphs {

BOOST_PARAMETER_NAME(graph)
BOOST_PARAMETER_NAME(visitor)
BOOST_PARAMETER_NAME(root_vertex)
BOOST_PARAMETER_NAME(index_map)
BOOST_PARAMETER_NAME(color_map)

CONTRACT_FUNCTION(
void (depth_first_search) (
        namespace tag, // optional namespace (tag assumed by default)
        in requires( // requires for type requirements
            boost::mpl::and_<
                  boost::is_convertible<
                      boost::graph_traits<boost::mpl::_>::traversal_category
                    , boost::indicence_grapth_tag
                  >
                , boost::is_convertible<
                      boost::graph_traits<boost::mpl::_>::traversal_category
                    , boost::vertex_list_graph_tag
                  >
            >
        ) graph, // this is required (because it has no default)
        in auto visitor, default boost::dfs_visitor<>(), // auto for
any type `*`
        in (typename boost::graph_traits<graphs::graph::_>::vertex_descriptor)
                root_vertex, default *boost::vertices(graph).first, //
with default so optional
        in requires(
            boost::mpl::and_<
                  boost::is_integral<
                      boost::property_traits<boost::mpl::_>::value_type
                  >
                , boost::is_same<
                      typename boost::graph_traits<graphs::graph::_>::
                            vertex_descriptor
                    , boost::property_traits<boost::mpl::_>::key_type
                  >
            >
        ) index_map, default boost::get(boost::vertex_index, graph),
        in out requires(
            boost::is_same<
                  typename boost::graph_traits<graphs::graph::_>::
                        vertex_descriptor
                , boost::property_traits<boost::mpl::_>::key_type
            >
        ) color_map,
                default default_color_map(boost::num_vertices(graph), index_map)
    )
    precondition(...)
    postcondition(...)
) {
    ...
}

} // namespace graphs

And for class templates:

namespace py {

BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType)
BOOST_PARAMETER_TEMPLATE_KEYWORD(BaseList)
BOOST_PARAMETER_TEMPLATE_KEYWORD(HeldType)
BOOST_PARAMETER_TEMPLATE_KEYWORD(Copyable)

CONTRACT_CLASS(
template(
    in typename ClassType,
    in typename BaseList, default boost::python::bases<>,
    in typename HeldType, default ValueType,
    in typename Copyable, default void
)
class (class_) requires(...) // concepts
) {
    ... // class invariants, members with pre/postconditions, etc
};

} // namespace py

struct b { virtual ~b() = 0; }
struct d : b { ~d(); }

typedef py::class_<b, boost::noncopyalbe> c1;
typedef py::class_< d, std::auto_ptr<d>, boost::python::bases<b> > c2;

IF I can do this (not sure yet), it should be beneficial especially
for class templates because all the boiler plate code (class template
skeleton A0, A1 = parameter::void_, class template signature, argument
pack, and parameter extraction) will be automatically generated by the
CONTRACT_CLASS macro.

Before I start diving into the implementation, what do you think of
this syntax for named parameters?

Thanks a lot.
--Lorenzo