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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-07 10:42:43

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.

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

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

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

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

That tells me an omitted component property is ignored when
making the match.  There is no need for the concept of a default
in that context, right?  Consequently, defaults only apply to
synthesis and, therefore, what you had should be fine.

> s/only/if and only if/?

Not necessary.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;