Re: [boost] Call for interest - BOOST_AUTO_FUNCTION

Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-10-28 10:51:49

On Thu, Oct 28, 2010 at 5:43 AM, David Abrahams <dave_at_[hidden]> wrote:

> Dude, are you kidding me?!  That is too amazing.
>

I'm glad other people are excited about it!

> Couple of questions:
>
> * What does an explicit concept map look like?  You didn't show an
>  example.
>

I haven't decided on what it will look like just yet, only the fundamental
mechanism that will be used under the hood. I'll post the way to specify
concept maps when I get there. One thing I'm pretty sure about is that I
could make it possible to create default implementations for concept maps
which you'd explicitly pull in when their definition is applicable to your
type. The default maps would forward associated types from, I.E. iterator
traits and directly use all operations directly. Such default maps would
likely be specified via a macro interface similar to BOOST_AUTO_FUNCTION.
Think something along the lines of a parameter to the macro with a keyword
ID of "typename" such as (typename iterator_traits< T >::value_type
value_type).

The neat thing about this is that since default implementations are
specified with such a macro, I can also convert the associated types and
expression requirements to something that can trigger SFINAE, meaning that
the macro can not only generate a default mapping, but can automatically
generate a metafunction that determines if a given type meets all of the
requirements that are specified.

As for full-on concept maps that specify all of the complicated glue code,
they will likely look not too dissimilar from simple traits classes.

> * Can you do concept map templates (e.g. all vector<T>s model
>  Container)?
>

Yes, I believe that should be possible and I'd also consider it a necessity
for such a library. However, it may end up being tricky when something has
concept maps specified for all vector<T> as well as only vector<bool>, but I
haven't gotten to that road just yet. There's likely a creative solution to
that problem.

> Not (break if not is_forward_iterator<...>) ?
>           ^^
>

The reason it's "break not" as opposed to "break if not" is because of the
problem I talked about earlier -- I can do multiword parameters as long as
there isn't a conflict. "break if not" would conflict with "break if".
Without getting too into the implementation details, it's because the first
word is concatenated with an implementation detail identifier to form a
macro which is invoked, then, if it's recognized as the first word of a
multi-word id it does it again, etc. The problem is, once it encounters the
"if", it can't safely try a further concatenation because if "not" isn't
there, there may be a token from an if condition such as a condition
starting with "(" or "!" which would cause an error during preprocessor
concatenation, despite the fact that the condition looks as though it should
be seemingly acceptable. As a side note, I may be able to get around this
limitation of conflicts in multiword IDs if I require all parameters that
appear after the IDs be surrounded by parentheses, since safely checking
ahead for if text is parenthesized is "possible," though hacky, but I don't
want to complicate use too much just for this.

Another thing to consider is that when your argument is a value, "break if
not" should technically work already since "not" will be treated by your
compiler there as its actual meaning. You, of course, can't rely on this
with arguments that are types.

Anyway, while I can't do "break if not" because it conflicts with "break
if", I can do "break not if" (and similarly "if" and "not if" as opposed to
"if" and "not", etc.) since there would be no conflict. In fact, I recently
started doing that very thing before I dropped the final "if" to simplify
implementation of the macro and because it was shorter to write out without
losing functionality.

But now I'm breaking my own rule by talking about the parameter ID names.

-- 
-Matt Calabrese