Dave Abrahams wrote:
on Mon Oct 24 2011, lcaminiti <lorcaminiti-AT-gmail.com> wrote:
Can you please explain better why it might be a problem if I always use the in, out, in out specifiers even with predicate type requirements?
I'm sorry, maybe I misunderstood. I thought the requires( ... ) clause was not part of a parameter declaration. Ultimately it would probably be syntactically superior if requirements were separated, but if that's not the case I can certainly live with it.
Yes, requires* is part of the parameter declaration and it is used to specify the predicate requirement on the parameter type. Note that my library does not add any feature to named parameters that is not already supported by Boost.Parameter (my library simply provides a different syntax for named parameters and then calls the Boost.Parameter macros behind the scene). My library will of course allow to add contracts to the functions and classes with named parameters (but contracts are the "only" added feature). (*) At the end my library will use `requires` in three places: (1) after template... to specify concepts, (2) before a named parameter name to specify the predicate type requirement, and (3) after a contract assertion to specify the assertion requirements. If this is confusing, I could easily use other pp-keywords (in fact, I can use any alphanumeric word I wish) but I think this re-use of requires is just fine and I'll document it well.
No, it's still too dense because of the comments (and the redundant optional "namespace tag"). Try again, please :-)
Sure, that's easy. Let me know if this still requires more work: #include <contract.hpp> using namespace boost; using namespace boost::mpl::placeholders; using namespace boost::python; 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) ( in requires(is_incidence_and_vertex_list_graph<_>) graph, in auto visitor, default dfs_visitor<>(), in (typename graph_traits<graph_type>::vertex_descriptor) root_vertex, default *vertices(graph).first, in requires(is_integral_property_map_of_key<_, typename graph_traits< graph_type>::vertex_descriptor>) index_map, default get(vertex_index, graph), in out requires(is_property_map_of_key<_, typename graph_traits< graph_type>::vertex_descriptor>) color_map, default default_color_map(num_vertices(graph), index_map) ) precondition( ... ) postcondition( ... ) ) { ... } } // namespace graphs namespace py { CONTRACT_FUNCTION( void (def) ( in (char const*) name, in auto func, deduce in (char const*) docstring, default "", deduce in requires(is_keyword_expression<_>) keywords, default no_keywords, deduce in requires(not_< or_<is_convertible<_, char const*>, is_keyword_expression<_> > >) policies, default default_call_policies ) precondition( ... ) postcondition( ... ) ) { ... } } // namespace py What do you think? --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/contract-syntax-redesign-tp3563993p393488... Sent from the Boost - Dev mailing list archive at Nabble.com.