Re: [boost] Re: [function types] Formal Review begins today.

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-06-07 17:13:42

On Tue, 07 Jun 2005 23:21:47 +0200
Tobias Schwinger <tschwinger_at_[hidden]> wrote:

> There is no runtime behaviour. If you violate preconditions you get an
> error and  the library takes some effort to give you a nice one, too.

I'm glad you spent effort to make sure the error messages were
meaningful.  A lot of template errors require a team of CIA agents to
decipher.

> The "maximum standard", however, is a very subjective thing - and
> existing  documentation of a library dealing with a similar topic may
> serve as an orientation.

Yup.

> No. This library only models the type system. Boost.Function (and
> alike) should  be allowed to use this library in the future (as
> higher-level components use  lower-level components not the other way
> around).
> 
> 
> However, here are two possible recipes of how a Boost.Function could
> be analyzed  with this library:

[snip ]

> Right. The upcoming versions of these libraries and of course the ones
> yet to  come should be encouraged to use this.

I think you are suggesting that these other libraries use function_type
in their implementation.  I'm suggesting that function_type should
provide some extra support for them (especially boost::function) evan as
a separate supplemental header file.

> >>You should not use it directly in 99% of all cases and use
> >>
> >>     is_function_kind<Tag, T>
> > 
> > 
> > Hmmm.  I do not see this anywhere in the online documentation.
> > 
> 
> <CITE>
> 
>   template<typename Tag, typename T>
>   struct is_function_type;
> 
> </CITE>
> 
> In fact it's in there two times ;-).

Hmmm.  In your first email you used is_function_kind, to which I said it
was not there, to which you replied that it is surely there, than proved
it by showing that is_function_type was there.  Maybe the first was a
typo?

> 
> > 
> >>instead. Actually there are no public functions to properly compare
> >>the tags so  you should stay away from this.
> > 
> > 
> > Actually, I was thinking of something more along the line of...
> > 
> > 	is_function_type<
> > 	    function_type_signature< foo_t >::kind,
> > 	    bar_t >::value
> > 
> > though function_kind would be nicer...
> > 
> 
> No - just simply: is_function_type<Tag,T>.
> 
> There really should be a note that these members are there, because
> they are  there and are not at all required for basic usage. It leads
> to too much confusion.

I still do not see how that gives me what I was looking for; checking to
see if a function type (i.e., bar_t) is an element of the set described
by the kind of another function type (i.e.,
the_tag_type_of_function_type<foo_t>).

> In most cases you won't need this class at all. Again, structuring
> into two  sections may help.

Sure, I think a restructuring may help in several areas.

> I must admit I had a strange feeling about the first rather fuzzy
> post.

I try to simply say what I think, but sometimes it does not come off
quite right, especially in email.  I am truly sorry for giving you the
strange impression.  Also, I appreciate your patience in the discussion.

Hopefully, I can actually find some time to look at the implementation
and try some examples myself, which would allow me to provide an
official review.