From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-07 09:38:44
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