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

From: Eric Niebler (eric_at_[hidden])
Date: 2007-04-26 17:44:45

Maurizio Vitale wrote:
> 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.

I doubt it would be less expensive to merely detect the error than to 
handle it correctly.

A thought. BOOST_PROTO_MAX_ARITY is primarily for controlling how many 
children a node in an expression tree is allowed to have. There's no 
good reason to tie it to the max arity of templates that 
proto::matches<> can handle. There should be a separate constant for 
that, and perhaps it could default to something higher than 5.

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

Totally agreed.

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

Yep, the docs are currently lacking.

> 
>>> 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::___.
>>
<snip>
> 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.

Doable, but not trivially. In all likelihood it'll make proto::matches<> 
compile slower in the general case. My gut feeling is that this feature 
isn't worth the trouble.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com