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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-10-13 21:30:26

On Sat, Oct 13, 2012 at 4:42 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> 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.

Also (like in Boost.Contract) the extra parenthesis are not required
but accepted around known alphanumeric identifiers like bool, void,
etc. If users for consistency wants to "parenthesize each statement"
including known alphanumeric identifiers, they can freely do so (even
if they are not required to).

> 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.

I used extends because that's what Boost.Contract uses for inheritance
(instead of the symbol ":" which cannot be used). I selected extends
in Boost.Contract for inheritance because that's what Java uses.
Refinements syntax uses ":" in the language so I'd us extends in the
lib. "default" instead of "as" probably makes sense. But we can have
detailed discussions about all these things (which are trivial to
implement after all) if/when I start implementing the font-end macros.

> Also, is there a reason why you are using "void" instead of just nothing
> for empty parameter lists and concept/concept map bodies?

Because MSVC pp sucks :( and gives errors (sometimes) if you use ( )
instead of ( void ). The lib actually accepts both ( ) and ( void ), (
void ) is more portable (it consistently works on MSVC) but users can
use ( ) if that's not a concern (e.g., GCC handle ( ) just fine and so
should Wave). That's the same story for Boost.Contract... I'm planning
to go back and double check exactly why MSVC breaks on ( ) before
Boost.Contract release (I might be able to impl a workaround).

> 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.

Does it consistently work on MSVC?

Thanks,
--Lorenzo