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.
proto mailing list

Reply via email to