Eric Niebler wrote:
Maurizio Vitale wrote:
In the code included, I define a class, K_aux, which inherits from meta_expression<typename proto::terminal<K<mpl::int_<N> >, Normally, objects of type K_aux match a pattern terminal<K<proto::_> >. I'm still fuzzy on why two layers of the type are skipped, but I'm fine with it.
Now, if K_aux defines a type named type (e.g. effectively becoming a nullary metafunction) the pattern doesn't match anymore.
Yep, I've known about this gotcha for a while and have been meaning to fix it before anybody noticed, but you beat me to it. :-P Proto uses the nested type named "type" to mean "the type of this expression", which was fine before proto::extends<> existed, but is dangerous and stupid once people start extending expression types. I'm sorry. Basically, I need to change all the nested types that Proto accesses to be proto-specific. So "type" becomes "proto_type", "tag_type" becomes "proto_tag", and even "arg0_type" becomes "proto_arg0", etc. This is a major breaking change, but it has to be done, and the sooner the better. Darn.
This bug should now be fixed. This involved a massive number of breaking renames, so I think this should probably break just about everybody. Sorry. The following Proto expression nested types/members have been renamed: type -> proto_base_expr tag_type -> proto_tag args -> proto_args arity -> proto_arity domain -> proto_domain arg0_type -> proto_arg0 arg1_type -> proto_arg1 ... ... boost_proto_expr_type_ -> proto_derived_expr cast() -> proto_base() In addition, there used to be a "proto::trans" namespace alias for proto::transform, and I've remove that. Bad idea. Gotta say "transform" now, or else create your own alias. -- Eric Niebler Boost Consulting www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com