Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2012-10-13 19:42:11

On Sat, Oct 13, 2012 at 5:52 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

> ... which is sounding more and more like Lorenzo should leave N3351
> alone, help Matt at least implementing a front-end macros like the
> ones below (s/CONTRACT_CONCEPT/BOOST_GENERIC_CONCEPT or similar), and
> use concepts defined using Boost.Generic in Boost.Contract requires
> clause.
>
>
> http://contractpp.svn.sourceforge.net/viewvc/contractpp/trunk/doc/html/contract__/concepts.html#contract__.concepts.concept_definitions__not_implemented_

That would be great. I still think it would be awesome if we had both
approaches implemented to the extent that is feasible, but I definitely
welcome an upgraded front-end if that's what you decide to do. I think I'm
fine now with not parenthesizing each "statement", despite my earlier
reservations. The only thing I think I'm not a fan of is the "keyword"
extends -- I used the keywords "concept" and "requires" for the macro
because they will likely be actual keywords in a future standard, so having
users highlight them in their IDE makes sense now anyway, since if they use
those words as identifiers elsewhere in their own code (separate from the
macro) they'll probably want to change them regardless, otherwise their
code will break with C++1y in the [hopefully] not TOO distant future. On
the other hand, if we have users highlight on "extends" it would highlight
their own valid identifiers named "extends", but that's a bit misleading
since "extends" is only really a special word when used in the macro (this
might not be as big a deal as I imagine, but if it can be avoided I think
it's for the best). I hate that Visual Studio highlighted "array" as a
keyword and I don't like the idea of encouraging people to manually do
something similar. I used "public" in the current implementation for
refinement just because it's already a keyword and I couldn't think of one
that was a better fit. If the front-end MUST have its own special word for
refinement as opposed to some other preprocessor-detectable syntax (such as
something like (,) ), I'd rather a standard or future standard keyword be
used than "extends" or "refines". Similarly, instead of using "as" for
associated type defaults, I think "default" might be better, even though
it's a bit more verbose.

Ultimately it's obviously up to you pending you're volunteering to do the
front-end overhaul, this is just my two cents.

Also, is there a reason why you are using "void" instead of just nothing
for empty parameter lists and concept/concept map bodies? I realize the
limitations of detecting emptiness in the preprocessor, but those
limitations generally don't matter for this type of library and I check for
emptiness in lots of places in the current implementation.

-- 
-Matt Calabrese