|
Boost : |
Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-10-28 17:44:22
Another thought that could prove interesting -- I could support a more
concise syntax along the lines of the following (note the lack of "template"
and any specific types being mentioned):
//////////
BOOST_CONCEPT_FUNCTION
( (foo)( (forward_iterator)( it ) )
, explicit decltype( it )
)
// Or even with references
BOOST_CONCEPT_FUNCTION
( (bar)( (forward_iterator&)( it ) )
, explicit decltype( it )
)
// Mix it with automatically deduced return types
BOOST_CONCEPT_FUNCTION
( (bar)( (forward_iterator&)( it ) )
, ( return ++it )
)
//////////
The above macro invocations would implicitly create templates without the
user having to do it manually. The idea here is that for
"BOOST_CONCEPT_FUNCTION", instead of using specific types in the parameter
list you'd use concepts, at least by default, and you avoid having to
explicitly create template parameters. If the types are needed in the
function, you can always use decltype( argument ).
There are some issues here still, for instance, what if this template needs
arguments for additional reasons (I.E. explicit template arguments such as
with Boost.Fusion "at", though in cases like that you could always have the
type instead be an MPL integral constant passed as a function argument,
specified as a parameter modeling such a concept, which has the positive
implications of being automatically concept checked as well as more
self-documenting).
Another concern is what if you need something analogous to this:
//////////
template< class It >
void advance( It& it, typename ::std::iterator_traits< It >::difference_type
difference );
//////////
I'd have to work in syntax such as the following (which I believe may be
possible to do exactly as written, with some more awful hacks):
//////////
BOOST_CONCEPT_FUNCTION
( (advance)( (forward_iterator&)( it ), (concept_map_of( it
)::difference_type)(difference) )
, explicit void
)
//////////
The latter would be able to do everything that the former can in about the
same amount of code but with concept checking on top. This is all just
hypothetical but should be possible.
I'm really getting too far ahead of myself now, though.
-- -Matt Calabrese
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk