|
Boost : |
Subject: Re: [boost] [contract] syntax redesign
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-10-24 19:01:39
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-tp3563993p3934888.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk