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.
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
