Dave Gomboc wrote:
The Function Type library uses tag types to represent a type's attributation, such as its calling convention or wether it is variadic.
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 has a particular value.
is_function< T, variadic > is_function< T, default_call >
Does it work?
It's better than before. I still think you shouldn't mix "uses tag types" (plural) with "a type's attributation" (singular), but you're the author. ;-) I'd still go with "to represent attributations of types", similar to how I wrote that line previously. Oh, also, fix the spelling of "whether".
I'm not a native English speaker and I know English has tighter restrictions than my mother language at this point. So there's a good chance my sentence is indeed ill-formed. The Function Type library uses tag types to represent one or more properties of a type. Each property describes an optional attribuation. The object of the sentence is plural now.
I have. Try these use cases:
// a remove constness (of the pointee) from a member function pointer type T function_type<signature<T>,tag<signature<T>,non_const> ::type
// shortcut: function_type<T, non_const >::type
or
// create a (possibly decorated) function type's variadic version function_type<signature<T>,tag<signature<T>,variadic> ::type
// shortcut: function_type<T, variadic >::type
Is manipulating these using MPL containers too much hassle for too little benefit?
In case you are referring to the shortcut: It's just syntactic sugar. In case you are referring to the tags: It would be overkill - tags hold expressions of bitwise integral arithmetic. In case you are referring to the function's component types: These /are/ specified by MPL sequences. If they are specified by a type that is not a sequence, a shortcut is triggered to create a sequence (signature<T>) from that type. Did any answer fit your question? I'ld be curious to know which one, then.
If <T, nonvariadic, variadic, variadic, nonvariadic, variadic> is really going to be the same as <T, variadic, nonvariadic, variadic>, then even testing for equivalence between tags becomes somewhat of a chore.
You shouldn't test tags for equivalence and the design keeps you from doing it. <snip> I cut this part of the discussion because it's based on a misunderstanding and far away from bringing us further. I'll try to clarify my point by ansering a tiny part of it:
"If I assign more than one value at the same time, I really mean the last one", which is different behaviour than runtime-C++ gives.
Why are you looking at a specialization of 'tag' being an assignment? It's a function! We can define functions like 'tag' in runtime C++ as well: tag_t tag(tag_t tag1, tag_t tag2) { // for each property in tag2: // assign that property value of tag2 to tag1 // return changed tag1 } Are you trying to say that a good interface must not contain such a function?
That's why this asymmetric disambiguation behaviour feels awkward to me.
Please note that the asymmetric behaviour is _essential_ and not for disambiguation: tag<signature<T>,a_property_tag> describes a transformation of T's properties. 'signature<T>' already contains all properties, the property value described by 'a_property_tag' is overridden! As a conclusion I will use this ^^ example in place of the obviously confusing "tag<variadic,non_variadic> nonsense". I apologize for adding to this confusion by my "loud thinking" in the previous post! Thanks, Tobias