Re: [boost] boost::proto, improving error handling

From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-04-26 08:52:00

Eric Niebler <eric_at_[hidden]> writes:

> I don't think there is anything I can do. To detect a template with a 
> too-high arity, I'd need specializations with at least that arity. And 
> if I have an arity-6 specialization, why not make it do the right thing 
> instead of reporting an error? 

If it has the same weight in terms of compilation time, of course.
I thought that maybe there was a cheaper way to detect the error, like a specialization
with some large number of default arguments that kicks in only above BOOST_PROTO_MAX_ARITY
and is not even defined, so that you get an error.

If it is not possible/desirable then the limit should be spelled out in the documentation,
both as a general rule and in the section on grammars, as it might not be obvious to the
newcomer that BOOST_PROTO_MAX_ARITY applies to patterns as well.

>> And I think that 6 is a better default value for the number of allowed arguments.
>> Just kidding, as long as defining it before including proto headers is officially
>> blessed and documented, I'm ok.
>
>
> It is. #define BOOST_PROTO_MAX_ARITY 6 should do the trick.

I know it works, but I don't think is in the documentation.

>> Another nice thing to have, although I would only put it in if very easy to code:
>> especially in presence of default parameters it might be nice to have a pattern matching
>> "the rest of the argument list". Something like a proto::___.
>
>
> Well, double-underscores are off-limits to user code, according to the 
> standard. 

Rats!

> But maybe you'd like something like:
>
>    std::basic_string< vararg<_> >
>
> to be the equivalent of
>
>    std::basic_string< _, _, _ >
>
> It doesn't seem like a big win to me, 

Well if it has to be that long, certainly not.

What about _n or _s? [the first would stay for N copies and
the second for the plural of _] or _*_ if one wants to get creative w/
operators.  The main question for me is whether it is hard to code and
whether it would impact the long term maintainability of the
library. If it is easy we can found a short name for it (actually I'm
not sure that _s is valid, although I believe it is).

Also, imo, to be useful shouldn't stay for "all the arguments", but
rather for "all the arguments that haven't been mentioned", so
std::basic_string<char,_s> would also be valid (and mean
std::basic_string<char,_,_> ). No idea whether this is doable.

> and it wouldn't solve the template 
> arity problem you ran into.

Clear. It is just that I thought of it while writing that mail and
was too lazy to start a new thread. Sorry.