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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-19 18:32:11

David Abrahams wrote:
> 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.
>

It was referring to the next sentence. "Rewinding" the discussion to one thought 
before the above part of your post...

> 
>>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'm not entirely sure there is, either. We agree enough, here.

> 
>>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.
> 

The next is not /that/ unusual (at least I've seen it in several places in Boost)...

> 
>>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.

This is only a good argument if no parametrization provides better usability, I 
guess ;-).

And we'll set reference decoration as the default (see further below) so you 
only see it if we want something else.

> 
> [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?]
> 

Did you mean:

      __attribute__(__whatever__) foooooooooooooooooooooo
      ( __attribute__(__whatever__) baaaaaaaaaaaaaaaaaaaaaaar
        ( __attribute__(__whatever__) baaaaaaaaaaaaaaaaaaaaaaaaaz
        ).get_something()
      ).get_something()

;-) ? I sure would!

> 
>>Sidenote: I'm not entirely sure on the MPL-Lamda expression
> 
  ^ in the following section
> 
> 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?

Because it hasn't been changed in documentation and the library, yet (so it's 
easier to follow our discussion) and 'class' conflicts with a keyword.

> 
> 
>>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?"

Whoops, sorry!

I had to re-read it three times to make any sense of it, myself.
And on second though the semantics I meant are no good.

Please, just ignore 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.

Did you think about iterating the sequences...

Thanks,

Tobias