Re: [boost] [function types][review]

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-19 17:12:37

Tobias Schwinger <tschwinger_at_[hidden]> writes:

> Hi Dave,
>
>
> David Abrahams wrote:
>> 
>> I can only explain the reasons I chose a reference and not a pointer
>> in the context of Boost.Python: pointers can be null, but references
>> cannot, and you can never call a member function on a null pointer.
>>
>
> We have to start a "bit further above" ;-).

I don't know what you mean.

> If we want to unify parameters and class type we have to either use a reference 
> or a pointer to it for things to make sense.

Yes.

> The by-value case (operator() member of a simple functor) is too unusual to make 
> sense in general.

Not sure what you mean here.  I don't think there's any case in which
a member function can reasonably have the target object passed by
value.

> I also agree, that a reference is the more reasonable default.
>
> Further, it is attractive to have a reference (as opposed to a value) in the 
> sequence because (e.g):
>
>      // Let t be a variable of type T and some
>      // T be some (member) function pointer/reference type
>      function< typename function_type<plain_function,T>::type > x = t;
>      //        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      // "rebinds" the subtypes of T to a plain_function
>
> will just work.

Right.

> I still don't think it is good to hard-wire this, though.

Why?

> If I understand your case correctly, you want remove const qualification of the 
> class type (which are not there, currently - but planned):
>
>      typename add_reference
>      < typename remove_cv
>         < typename remove_reference
>            < typename function_type_class<T>::type
>              // or typename at_c<sig,1>::type
>            >::type
>         >::type
>      >::type

Yes, but I don't really think this library should make any special
allowances for my weird case.  Boost.Python may not be able to use
this library anyway because of the need for vc6/7 compatibility, but
if it can, I'll strip the cv-qualification myself.

> Slightly better for those who want a pointer:
>
>      typename add_pointer
>      < typename remove_reference
>        < typename function_type_class<T>::type
>          // or typename at_c<sig,1>::type
>        >::type
>      >::type
>
> So I believe it is perhaps best to parametrize the decoartion we want on the 
> class type:

I disagree.  Too much parameterization is an impediment to usability.

[BTW, so is the endline layout you're using for nested templates.
There's little precedent for it anywhere that I've seen.  You wouldn't
write

   foo
   ( bar
     ( baz(1)
     )
   );

would you?]

> Sidenote: I'm not entirely sure on the MPL-Lamda expression

Your posting didn't show one above, although I can guess what the example
you would have written would look like.

> - we could also use 
> some kind of tag type or an enum, I guess. Or we use MPL-Lambda exressions, but 
> only evaluate them as a fallback when there is no optimized specialization, as 
> for add_reference<_>, add_pointer<_> and identity<_> (maybe even one to create 
> an unqualified reference for the Boost.Python case). Thoughts welcome.
>
>      template<typename T, typename ClassDecoration = add_reference<_> >
>      struct function_type_signature;
>
>      template<typename T, typename ClassDecoration = add_reference<_> >
>      struct function_type_class;
>
> And if we want to add a unified one:
>
>      template<typename T, typename ClassDecoartion = add_reference<_> >
>      struct function_type_effective_parameters;
>
> (Jonathan Turkanis has suggested adding one like this. He also came up with 
> "effective" for the name, which I happen to like).

Remind me again why you're still using the function_type_ prefix?

> And perhaps even:
>
>      template<typename Tag, typename TypeOrTypes,
>               typename ClassDecoartion = add_reference<_> >
>      struct function_type;
>      // ignores it, unless it specializes function_type_signature
                  ^^         ^^
                  what are these?  Are they the same "it?"
>
> Revisiting the example from above we could say:
>
>      function< typename function_type<plain_function,T,add_pointer<_> >::type >
>
> And easily even use our favourite proxy, e.g. a smart pointer...

Now that you bring that case up, parameterization starts to look a bit
more attractive.  I'm still leary of going in that direction, though.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com