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