Re: [boost] [contract] syntax redesign

Subject: Re: [boost] [contract] syntax redesign
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2011-06-04 16:25:08

On Sat, Jun 4, 2011 at 3:37 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

> This still keeps public that is highlighted (BTW, in the library docs
> I will provide the DSEL grammar and a list of the new "keyword" like
> extends, requires, precondition, etc so you can configure your IDE to
> color them up)

Yeah, I set my IDE to highlight requires as well, as you can see in the
slides, but the thing I don't really like about doing it for "extends", is
that it's likely not going to be a keyword even in the standard after 0x.
So, if someone uses "extends" in their code in a place completely separate
from the macro, I think it's not a great idea to have it highlight,
otherwise it makes it seem like a user should not be using "extends" as an
identifier when in actuality it's perfectly fine. For words like requires,
however, since it's very likely that in the next standard it will be a
keyword anyway, it's probably a good thing that people see it highlighted
now since using it as an identifier will probably break sometime in the next
decade (perhaps I'm being optimistic :p).

> I used ", default ..." for default parameters:
>
>    (MoveConstructible) reference, default typename x::reference
>

Yeah, I really like your use of default there! I'm going to give it some
thought, and I probably will go that route too.

To handle unparenthesized commas, I'd use the IDENTITY_TYPE/VALUE
> macros. Commas not wrapped within parenthesis are rare so IMO it's not
> worth to ask users to always use extra parenthesis to handle them.
> It's simpler to ask user to use a special macro when they are present.
>

I'm not too sure that I agree with the statement that top-level commas are
rare. Templates with multiple parameters aren't that uncommon in the real
world, are they? Or am I really out-of-touch with the "real world" here (I
admit, this is a possibility, but at least of those who would use a macro
library like this, I think it's not that odd)? Either way, if it really is
rare, I think I still would rather have the user not have to do anything
different when they eventually do write a typedef that contains commas. I
like having the corner-cases work with the same syntax as the common case.

Error reporting is a good point especially because all your code is
> within the macros (for Boost.Local the function body code is outside
> the macro and that's were most of the actual programming errors will
> be so I likely don't have to worry about error reporting too much -- I
> still check the syntax using the pp as much as possible).
>

Yeah, error reporting at preprocessor time ends up being a huge hassle for
me, though I've got it down to a system that's not too difficult to manage
now. I've even started checking during preprocessing that associated
operators have the correct amount of parameters so that users don't get
compile-errors in generated code.

   , (postincrement_result) operator(++, postinc)( X&, int )
>
> That's a tuple and X& is the only token... why can't you just get it with:
>
>    PP_VARIADIC_TUPLE_ELEM(0, (X&, int)) // expand to X&
>

> I am missing something here... maybe sometimes you have some other
> tokens like in ( (X&) x, int y ) ??
>

Yup, that's exactly it. The issue is that the user can optionally provide a
name for each individual parameter (this is true for all of my parameter
lists). So while yes, if a user doesn't provide a name, I can pull out the
individual parameter type, but if a name is provided then I can't separate
the parameter name from the parameter type, which I need to do underneath
the hood. Without the parameter being parenthesized or it being a known name
such as int, I can't determine if a parameter name is even there, let alone
separate that name from the type.

> Thanks to you to take a look at Boost.Contract newer syntax. BTW, this
> is major syntax re-design #4 for Boost.Contract... it requires a lot
> of patience and perseverance :)
>

Yeah, definitely understood! Awesome work.

-- 
-Matt Calabrese