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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-07 08:24:29

From: Tobias Schwinger <tschwinger_at_[hidden]>
> Rob Stewart wrote:
> > From: Tobias Schwinger <tschwinger_at_[hidden]>
> > 
> 
> 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).

Shortly after posting, I found the new thread.  Oh well.

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

I've been reading that thread.  Thanks for the heads up.

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

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.

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

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

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

OK.  I see.

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

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

> >>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?  Did I miss/forget you discussing
defaults in the context of classification?

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