Rob Stewart wrote:
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.
In fact, that's probably not too bad of a point...
Note that a function type can be decorated--to use your term--to *form* a pointer to function, for example.
Being picky I guess you meant "a pointer to function *type*" - otherwise "form" should be "declare" ;-). ...and other compound types, such as function pointer, function reference and member function types. I believe I can get rid of that term in the rest of the text as well.
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.
Something along those lines. How's Default values are selected for properties not specified by the tag here (see <somewhere else>). ?
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...."
OK. Let's get rid of the "decorate" artefact: ...creates the type of a function (variadic in this case) of the default... Thanks, Tobias