Re: [boost] [function_type] Tag types documentation
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 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? 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.
Well, we /could/ only allow overriding only in this very context, however, it would make things inconsistent and more complicated to explain, IMO. I don't see a problem in allowing it either, because most error situations are pretty obvious
a = 1; a = 2; // <-- should this line fail to compile?
No, your example above is (roughly speaking) X = tag<T, nonvariadic>; X = tag<T, variadic>; Which sequentially assigns different values to X. By writing tag<T, variadic, nonvariadic>, to my eyes you're writing something akin to "a = 1 and a = 2 (at the same time)" [One example in runtime-C++ is calling f(a=1, a=2), which does not at all guarantee that a=2 at the end of this expression! But a guru may come up with a better example.] Then, you specify a rule that says "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. That's why this asymmetric disambiguation behaviour feels awkward to me.
plus 'tag' seldom has to be used directly by the user, anyway.
Further there is the technical side of the story:
tag<A,B>
only describes a type (talking C++ type system context here) and thus does not trigger a template instantiation. So the error message you get would probably involve a lot of trace (to where its PoI is) output and be questionable useful, because of this.
Explicit instantiation of templates is our friend in such cases. This is nothing new to template users. Dave
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
Tobias Schwinger <tschwinger@neoscientists.org> writes:
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.
"Attribuation?" Where did that word come from? I don't even think it exists in English. Do you mean "attribute?" If so, how does that add anything? "Attribute" is just a synonym for "property." -- Dave Abrahams Boost Consulting www.boost-consulting.com
The Function Type library uses tag types to represent a type's properties, such as its calling convention or whether it is variadic. How do I make this valid English (plural tag types, singular type)? Thanks, Tobias
Tobias Schwinger <tschwinger@neoscientists.org> writes:
The Function Type library uses tag types to represent a type's properties, such as its calling convention or whether it is variadic.
How do I make this valid English (plural tag types, singular type)?
It's fine as is. I'd call this library "Function Types" (plural, like "Type Traits") but that that's just me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
The Function Type library uses tag types to represent a type's properties, such as its calling convention or whether it is variadic.
How do I make this valid English (plural tag types, singular type)?
It's fine as is.
Great!
I'd call this library "Function Types" (plural, like "Type Traits") but that that's just me.
Well, actually I prefer Function Types too (btw. the current draft contains a class template with the same name as the namespace)... So - is our rationale good enough to violate the Boost guidelines at this point? Thanks, Tobias
Tobias Schwinger <tschwinger@neoscientists.org> writes:
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
The Function Type library uses tag types to represent a type's properties, such as its calling convention or whether it is variadic.
How do I make this valid English (plural tag types, singular type)?
It's fine as is.
Great!
I'd call this library "Function Types" (plural, like "Type Traits") but that that's just me.
Well, actually I prefer Function Types too (btw. the current draft contains a class template with the same name as the namespace)...
So - is our rationale good enough to violate the Boost guidelines at this point?
Which guideline are you proposing to violate? What rationale? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
The Function Type library uses tag types to represent a type's properties, such as its calling convention or whether it is variadic.
How do I make this valid English (plural tag types, singular type)?
It's fine as is.
Great!
I'd call this library "Function Types" (plural, like "Type Traits") but that that's just me.
Well, actually I prefer Function Types too (btw. the current draft contains a class template with the same name as the namespace)...
So - is our rationale good enough to violate the Boost guidelines at this point?
Which guideline are you proposing to violate? What rationale?
Which guideline? http://www.boost.org/more/lib_guide.htm#Naming%AD_consistency However, I just re-read it and "are usually singular" is less strict than what I had remembered, so "violate" might have been the wrong word. What rationale? - Consistency with Boost.TypeTraits - Avoid possible name conflict with a well-named component of the library itself Regards, Tobias
participants (3)
-
Dave Gomboc -
David Abrahams -
Tobias Schwinger