From: Tobias Schwinger <tschwinger@neoscientists.org>
Rob Stewart wrote:
From: Tobias Schwinger <tschwinger@neoscientists.org>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;