Re: [boost] [function types] New tag type logic [update2]

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-06 16:04:34

Rob Stewart wrote:
> From: Tobias Schwinger <tschwinger_at_[hidden]>
> 
>>Here we go again. The next update. Big thanks go to Rob Stewart and David Abrahams 
>>for their helping with this text.
> 
> 
> You're welcome.  I'm glad to help.
> 
> 
>>There is a version of this passage with markup: http://tinyurl.com/bxvke
>>
>>Can we freeze this part?
> 
> 
> I don't think it is finished yet, but it is a vast improvement
> over the earlier versions.
> 

Rob,

I'm sorry to say that you are using a slightly outdated version. I'll try to merge 
your suggestions in, though (I always post the most recent update to the "Review 
Result" thread).

Some more things have changed (e.g. there is no decoration aspect anymore) so you 
might want to take a look at the more recent stuff and discussion if things seem 
strange to you in my reply.

> 
>>Tag Types
>>----------
>>
>>The Function Type library uses tag types to represent one more properties of a 
>>type, such as its variadicness or whether the function is decorated with a pointer.
> 
> 
>    function type, such as whether it is variadic or is a pointer
>    to a function.
> 
> I dislike "variadicness."
> 
> It just struck me that a type is never decorated with a pointer,
> though it can be a pointer to another type.  Hence, "is a pointer
> to a function" rather than "decorated with a pointer."

Seems solved.

    The Function Types library uses tag types to represent a type's properties,
    such as its calling convention or whether it is variadic.

> 
> 
>>Tags that represent the values of a single property are called property tags. 
>>These tags can be used to determine whether one property of a type or another tag 
>>has a particular value.
>>
>>     is_function< T, variadic >
>>     is_function< T, pointer >
>>
>>A compound property tag describes a combination of possible values of different 
>>properties. The tag class template can be used to create a specific compound 
>>property tag.
>>
>>     tag<pointer,variadic> // describes a pointer to a variadic function
>>
>>When several tags for the same property appear in the argument list, only the last 
> 
> 
> I think this may have bounced around already, but "the argument
> list" sounds too vague to me.  It should be "tag's argument
> list."
>

Hmm... We're talking about "class template tag" at this point. On second thought 
adding "in tag's" seems good to me, because other class templates are used in the 
following text.

> 
>>one is used; others are ignored.
> 
> 
> s/others/all others/

Why? I don't see it's necessary.

> 
> 
>>     tag<pointer,reference> // same as 'reference'
> 
> 
> s/'reference'/tag<reference>/
> 

It won't work, since the unary version of tag is an artefact I overlooked updating 
the synopsis (shame on me). Further, this example will be thrown out, anyway.

> 
>>The following code creates the type int(*)(int...).
>>
>>     function_type<mpl::vector<int,int>, tag<pointer,variadic> >::type
>>
>>All properties not described by the tag acquire a default. The next example 
> 
> 
>    All properties have a default tag.  If you don't specify a tag
>    for a property, that property's default tag is used instead.
>    The following expression

There are no "default tags" - there is a default value, but the "default tags" 
(which used to be the fully general "abstract" ones) have been removed from the 
interface).

With this issue adjusted your suggestion might be OK. However, I don't see why it 
should be better: It uses more words to essentially say the same thing and seems 
to be cut-off from the previous example (it shouldn't). Further I'm pretty sure 
I'ld personally prefer the original being the reader (but that's perhaps just me).

> 
> 
>>creates the type of an undecorated (variadic) function of the default calling 
> 
> 
> s/ (variadic)/, variadic/

"Variadic" is in parentheses to denote that it doesn't make up the point here.

s/(variadic)// # but I'm not sure

> s/of the default/with the default/

OK.

> 
> 
>>convention: int(int...).
>>
>>     function_type<mpl::vector<int,int>, variadic >::type
> 
> 
> Do the defaults only apply to synthesis?  

Well, sort of.

> You only show/describe their use in that context.

?! I thought that's what I do. This paragraph (and the previous two or so) about 
using tags in terms of synthesis...

> 
> I haven't looked at the text with markup, but the following text
> seems disjoint from the foregoing:
> 

Yeah, because we shift to classification here.

> 
>>A compound property tag matches a type only when all of its component properties 
>>match:
>>
>>     is_function< void(&)(...)   , tag<reference,variadic> >::value // is true
>>     is_function< void(X::*)(...), tag<reference,variadic> >::value // is false
> 
> 
> Since this example uses is_function as the earlier examples did,
> perhaps you could move this part ahead of "The following code
> creates the type int(*)(int...)" part.
> 

OK. Things read smoother this way.

Thanks,

Tobias