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