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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-07 12:02:54

Rob Stewart wrote:
> From: Tobias Schwinger <tschwinger_at_[hidden]>
> 
>>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.
> 
> 
> Maybe I'm being too picky, but a pointer doesn't decorate a
> function type.  You can have a pointer to a function, which has
> type pointer to function, but a pointer, which is a variable
> holding an address (ignoring pointers to member functions) can't
> decorate a type.

In fact, that's probably not too bad of a point...

> 
> Note that a function type can be decorated--to use your term--to
> *form* a pointer to function, for example.
> 

Being picky I guess you meant "a pointer to function *type*" - otherwise "form" 
should be "declare" ;-).

    ...and other compound types, such as function pointer, function reference and
    member function types.

I believe I can get rid of that term in the rest of the text as well.

> 
>>>>>>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").
> 
> 
> I think I see what you're trying to say.  Perhaps the right
> wording is that "a default value is used for a missing property
> when synthesizing a type," or something along those lines.

Something along those lines. How's

    Default values are selected for properties not specified by the tag here (see
    <somewhere else>).

?

> 
> 
>>>>>>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.
> 
> 
> I see.  How about, "creates the type of an undecorated function
> (variadic in this case) of the default...."
>

OK. Let's get rid of the "decorate" artefact:

    ...creates the type of a function (variadic in this case) of the default...

Thanks,

Tobias