On 12/7/2010 3:13 PM, Thomas Heller wrote: > Eric Niebler wrote: >> Now they do: T()(e,s,d). Inside T::impl, D had better be the type of d. >> Nowhere does the _data transform appear in this code, so changing _data >> to be "smart" about environments and scopes won't save you if you've >> monkeyed with the data parameter. > > Very true. Something like proto::transform_env_impl could help. Introduce a > new type of primitive transform which is aware of this environment. The > usual transform_impl can still be used. > By calling T()(e,s,d) you just create a 2-tuple. The first parameter is the > state, second data. > Just thinking out loud here ...
So transform_impl strips the data parameter of the let scope stuff, and the local variables like _a don't use transform_impl and see the scope with the locals? Well, it's not that simple.... Consider: make< int(_a) > If make::impl uses transform_impl, it strips the let scope before _a gets to see the local variables. If this is to work, most of Proto's transforms must be "special" and pass the let scope through. That means proto::call, proto::make, proto::lazy and proto::when, at least. But ... it just might work. Good thinking! <time passes...> No, wait a minute. Look again: struct T : transform<T> { template<class E, class S, class D> struct impl : transform_impl<E, S, D> { // do something with D }; }; T::impl gets passed D *before* transform_impl has a change to fix it up. Any existing transform that actually uses D and assumes it's what they passed in is going to be totally hosed. In order to make existing transforms let-friendly, they would all need to be changed. That's no good. Bummer, I was excited for a minute there. :-/ -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto