Re: [boost] Formal Review: Concept Checking Library

From: Matthew Austern (austern_at_[hidden])
Date: 2000-11-20 17:58:19

In a sense, this is the third time that I'm reviewing Jeremy's
concept checking work!  (First when an earlier version was added
to the SGI library, and again when a concept checking paper was
submitted to the Erfurt workshop.)

My reaction now is the same as both other times: it should be
included, because it's a big advance on what came before, but
it should still be thought of as semi-experimental.  I hope that
people continue to think about other forms of concept checking.

Some specific issues:
 - A big advantage: it allows authors of function and class
   template a way to put all of their requirements in one
   place, other than with comments.  Unlike some other concept
   checking proposals, it's flexible enough so that it can 
   accommodate the wide variety of constraints that we see in
   template-based C++ libraries.  So if nothing else, at least
   this gives us enforceable documentation.

 - Potential disadvantage, which really needs more study:
   does this actually do what it promises?  Are the error 
   messages from concept checking really easier to understand
   than the error messages we have without it?  That's especially
   a concern if we're taking about a very simple template, like
   for_each, and a very complicated concept checking macro.
   (Aside: I think that some of the GNU people are doing 
   experiments where the front end would recognize concept 
   checking assertions and use them when generating error 
   messages.  Concept checking that straddles the library/
   compiler boundary might be a promising direction to go in.)

 - An advantage or disadvantage, depending on how you look at
   it: concept checking exposes a lot of cases where user
   code just happens to work, even though the specs never
   guarantee that it's supposed to.  (For example,
   std::map<const int, int> doesn't work with the latest
   SGI STL, but it did work with an earlier version.)  By
   and large, I think this is an advantage; it's good for
   these things to break visibly.

 - I keep hoping that there might be a way to eliminate the
   use of macros.  Token pasting, in particular, is distasteful.
   On the other hand, I can certainly see the advantage of
   sparing users the sight of disgusting constructs like
   taking the address of a function pointer and putting the
   whole thing in a never-executed do/while loop.

 - Something that's missing: an explanation of the low-level
   constructs that appear in concept_checks.hpp.  Users who
   want to write their own concept checks need to understand
   not just how to write a constraints() member function, but
   also specifics like require_boolean_expr and 
   ignore_unused_variable_warning.  I can use the code in
   concept_checks.hpp as a model, but users should be able
   to get that from the documentation.

 - A stylistic issue (and here I'm showing my ignorance of
   standard BOOST usage): Is it appropriate to have variables
   with names like __f, and _First, and macros with names like
   __STL_DEFINE_BINARY_OPERATOR_CONSTRAINT?  Names like that
   are reserved for the implementation.  What I don't know is
   whether this file is considered implementation code or
   user code.

                        --Matt