Proto for Boost mailing list page: Re: [proto] Problems with unary function node

Subject: Re: [proto] Problems with unary function node
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-10-29 05:19:38

On 10/29/2011 06:37 AM, Eric Niebler wrote:

> It could be that I'm stupid, or that I'm tired, or that your explanation
> is insufficient ... but I don't get it.

My explanation is just a few bits from what kind of thing we do, sorry 
it wasn't helpful. It may help to say that it's not the actual 
expression that I'm categorizing, but its children.

A generator like that would be problematic for example

typedef typename proto::result_of::child_c<Expr&, 0>::type child0;
typename result_of<proto::_default(child0)>::type result_type;

result_type operator()( Expr& expr
                       , typename impl::state_param
                       , typename impl::data_param
                       )
{
   return proto::_default()(proto::child_c<0>(expr));
}

In the case of operator()(), child0 would be the expression< 
terminal<...> >, which is also incomplete.

Now that's not a very good thing for a generator to do, but some 
generators require in our case to do some manipulations with somewhat 
complex transforms on the children.

  Regardless, it seems to me that
> you still want your expressions to have a unary function operator, but
> that you don't want to compute its return type eagerly.

Ideally yes, but it's pretty simple, so I specialized the generator for 
that case and avoided introspecting the type.

> And as you said,
> that's just not possible in today's language. My patch solves the
> problem only for those people who want to turn off unary function
> completely. Ditto for assign.

Ok, I think it's a good thing. Do you have an idea of how much 
compile-time it costs to do so?

>
> What should you do? Avoid calling those generic categorization
> metafunctions in your generator. The generator has to assume the type it
> computes is incomplete.

That's quite a severe restriction.
It's only necessary for operator()() and operator=(expression const&), 
so I'd rather I don't have to apply this restriction to the other node 
types.

I think this should be documented.