Proto for Boost mailing list page: Re: [proto] Hold terminals by "smart" reference

Subject: Re: [proto] Hold terminals by "smart" reference
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-06-06 02:09:04

On 05/06/2012 20:38, Eric Niebler wrote:

> I want you to understand that I'm not just being obstructionist or
> obstinate. Proto's value functions are very simple and low-level and are
> called very frequently. Adding metaprogramming overhead there, as would
> be necessary for adding a customization point, has the potential to slow
> compiles down for everybody, as well as complicating the code, tests and
> docs.

The change required to provide this feature is to replace the 
implementation of value from

return e.proto_base().child0;

to

return e.proto_base().value();

and of course to change the specialization of (basic_)expr<Tag, 
term<Arg>, 0> accordingly.

That is all. I'm not sure this complicates the code, albeit for good 
measure it would be nice to avoid the use of the name proto_child0 for 
the type of the terminal, too.

> There are also unanswered questions. For instance, how does
> proto::matches work with these terminals?

I'm not terribly familiar with how proto::matches works, but if it uses 
the proto_grammar typedef, then it could be made so that it wouldn't 
notice any difference.

> Does it match on the actual
> value or the logical one? There are arguments on both sides, but one
> needs to be picked. Going with the logical value will force
> proto::matches to go through this customization point for every
> terminal. I also am thinking about how it effects other proto features
> such as: as_expr, as_child, make_expr, unpack_expr, literal+lit, fusion
> integration, display_expr, fold and all the other transforms, etc. etc.

I doubt any of these rely on specific implementation details of 
basic_expr<Tag, term<Arg>, 0>, so they wouldn't be affected.

> Making proto's user's happy must be balanced against feature-creep-ism,
> which hurts everybody in the long run. So I'm afraid I'm still leaning
> against adding this customization point.

No problem, I thought it would have been an interesting addition.