Re: [boost] [review] Fusion review, finalization

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-15 16:55:50

Tobias Schwinger wrote:
> Joel de Guzman wrote:
>> Tobias Schwinger wrote:

>> In Phoenix,
>> I had to go through hoops just to disable_if the nullary operator().
>> Eager evaluation wreaks havoc! Look:
>>
>>      typename
>>          mpl::eval_if<
>>              typename Eval::no_nullary
>>                 // avoid calling apply_actor when this is true
>>            , mpl::identity<detail::error_expecting_arguments>
>>            , apply_actor<eval_type, basic_environment<> >
>>          >::type
>>      operator()() const;
>>
> 
> Interesting. Just curious: how would you mask "nullaries" whith a non-member template function? 

You don't. It just works because templates are delayed. If
operator()() can be a non-member, I would write that as:

     template <typename Actor>
     actor_result<typename Actor::eval_type, basic_environment<> >
     operator()(Actor const& actor);

> Something different (that sentence just brought it back to my mind):
> 
> I noticd that fusion::pair<end>(begin) works quite well as a "compound iterator" but has a pretty uncool interface. A wrapper around it could give a useful utility... 
> 
>   'in' is of type fusion::pair<end>(pos), 
>   '==>' denotes interface transformation provided by an imaginary wrapper
> 
>   *in.second ==> *in
>   equal_to<typename In::first_type, typename In::second_type> ==> eoi<In>
> 
> Since this thing knows when it's at the end, it could (BTW) even have an operator-> that disappears in this case...

I'd refrain from commenting right now because I realized I might
have been wrong. I think now that Dave is correct that we can
detect an iterator pointing nowhere and simply return void_ or
something like I did above for Phoenix.

Thanks!
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net