Subject: Re: [boost] [contract] syntax redesign
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-05-31 17:59:08
Matt Calabrese wrote:
> On Tue, May 31, 2011 at 5:21 PM, lcaminiti <lorcaminiti_at_[hidden]>
>> If the return type is a "keyword" known a priori like void then no
>> parenthesis should be needed.
> Oh, so you just special-cased some keywords and the rest require
> parentheses? That's good. The only criticism I have of that is that it's
> inconsistent. I had some special-casing to eliminate parentheses, similar
> what you are doing, but I ultimately sided on being consistent over
> everything else. That's obviously just my opinion, so I'm not saying you
> should definitely change it, it's just something to consider.
Yes, I was also concerned about inconsistency so I decided that the syntax
will always accept parenthesized types. You can (but don't have to) omit the
parenthesis for a known "keyword". This way users can choose as they wish.
In other words, the following will both be accepted by the same macros:
CONTRACT_FUNCTION( (void) (f)() ) // (1)
CONTRACT_FUNCTION( void (f)() ) // (2)
If you are worry about consistency, you use (1). If you are worried abut
extra parenthesis, you use (2).
> Also, given your description (using IS_UNARY), it sounds as though your
> current implementation cannot handle return types that have top-level
> commas. For instance, you can't return a boost::array< int, 2 > directly
> without using a typedef (and if that return type is dependent on the
> function's template parameters then you could potentially be stuck). I
> highly recommend that you use variadic macros here to directly check if
> anything parenthesized other than empty. It looks like you're already
Boost.Local's BOOST_IDENTITY_TYPE can be used to handle un-parenthesized
commas within macro parameters (see
> relying on variadic macros for your parameter lists, so you wouldn't be
> introducing further compiler requirements.
Similarly to Boost.Local, the syntax will require parenthesis on
preprocessors without variadics:
CONTRACT_FUNCTION( void (f)( (int x) (int y) ) ... ) // no variadics
must use this
With variadics, you can still use the above or alternatively the same macros
will accept commas:
CONTRACT_FUNCTION( void (f)( int x, int y ) ... ) // variadics can (but
don't have to) use this
>> I have done some experimentation that indicates this syntax _should_ be
>> possible but it's not actually implemented yet so... we'll see :)
> It's definitely possible, yes.
-- View this message in context: http://boost.2283326.n4.nabble.com/contract-syntax-redesign-tp3563993p3564468.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