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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-07 09:38:44

Rob Stewart wrote:
> 
> Yep, although ISTR some remaining reference to a function type
> being "decorated with a pointer."  Be on the lookout for that
> phrasing in your new version.
> 

The term should be OK, I figure. Since the Overview section starts with this text:

     This library provides functionality to classify, decompose and synthesize
     function types and other compound types directly decorating a function type
     with a pointer, reference or member pointer.

     [... explains what this means in other words and gives examples]

I'll try to post a preview soon.

> 
>>>>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.
> 
> 
> It's not just that.  There's already been mention of is_function,
> for example.  The change just ensures that the reader is thinking
> about tag's template argument list.
> 

OK. "in tag's"'s in already ;-).

> 
>>>>one is used; others are ignored.
>>>
>>>s/others/all others/
>>
>>Why? I don't see it's necessary.
> 
> 
> "Others are ignored," even if it was taken from an earlier
> suggestion of mine, sounds a bit abrupt.  Adding "all" makes it
> sound better.  (It isn't needed for clarity, just readability.)
>

OK.

>>>>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).
> 
> 
> A property cannot acquire anything; "acquire" is a transitive
> verb.  It has things that define it, but it cannot add to those
> things.  Hence my phrasing: "properties have a default."
> 

I'm not sure I understand you correctly.

The default is a function -- not a constant. I don't believe "have a default" is 
entirely correct here.

The property acquires (even if it may not work English-wise ;-) ) a value based on 
the context the tag is used in (and I believe explaining this doesn't really help 
the user, who only needs to know "there's a default behaviour by definition - I 
gotta look it up").

>>>>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
> 
> 
> As written, the text suggests the possibility of
> "function/variadic function."  The example creates a variadic
> function type, right?  Therefore, "variadic" shouldn't be in
> parentheses.
>

The examples just specifies one property tag (which has nothing to do with what 
I'm trying to show -- but I can't show it not specifying a tag at all, because of 
the default argument -- which btw. is consistent with the rest but defaulting is 
nothing special for a default argument) so the text can tell the other property 
defaults.

> 
>>>>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...
>  
> But the section is about properties plus their defaults, not
> about type synthesis, right?  

/These/ defaults only apply to synthesis. It doesn't have to be spelled out 
because....

> Did I miss/forget you discussing defaults in the context of classification?

"A compound property tag matches a type only when all of its component properties
match". Well, this tells you what it means not to specify a property for 
classification, doesn't it?

s/only/if and only if/?

Thanks,

Tobias