Re: [boost] [function_type] Tag types documentation
Tag Types: ----------
The Function Type library uses tag types to represent one more attributive properties of a type, such as its variadicness or its calling convention.
"one more"? Did you mean "one or more"? "a type"? It might be one type per tag, but tagging can be applied to more than one type, so this should be rephrased. "variadicness"? I think you meant "variadicity". I'm not thrilled by "attributive properties" either. My discomforture with this phrase is due to its perceived redundancy. Is it common for properties to exist that attribute nothing? I propose: The Function Type library uses tag types to denote properties of types. For example, the tag tag<fastcall, variadic> may be used to denote use of the fast calling convention in combination with variadicity.
When several tags for the same property appear in the argument list, only the last one is used; others are ignored.
tag<nonvariadic,variadic> // same as 'variadic'
The semantics of tag<nonvariadic, variadic> should be identical to the semantics of tag<variadic, nonvariadic>. It strikes me as erroneous that this combination of denotations would not yield a compilation error. Have you a well-founded argument for this choice? I'm new to this thread; apologies if I'm rehashing something that was settled earlier. Dave Gomboc
Dave Gomboc wrote:
Tag Types: ----------
The Function Type library uses tag types to represent one more attributive properties of a type, such as its variadicness or its calling convention.
"one more"? Did you mean "one or more"?
Yes. It got lost, somehow...
"a type"? It might be one type per tag, but tagging can be applied to more than one type, so this should be rephrased.
Well, not at once. It's a 1..* relation: one type --- N tags to describe its attributes This all can happen M times, so we have a "infinity != infinity * infinity" situation here. This is why I'm not sure if making it plural is a good here.
"variadicness"? I think you meant "variadicity".
I'm not sure "variadicity" is a word either. Sorry, I copied this from David Abrahams' proposal assuming it was correct. I'll use "whether it is variadic" instead...
I'm not thrilled by "attributive properties" either. My discomforture with this phrase is due to its perceived redundancy. Is it common for properties to exist that attribute nothing?
I recently excluded the "decoration" property (pointer, reference,member pointer or plain function type) from this set (so "attributive" is meant as opposed to "fundamental"). I agree it's not perfect. s/attributive properties/attributation/
I propose:
The Function Type library uses tag types to denote properties of types. For example, the tag
tag<fastcall, variadic>
may be used to denote use of the fast calling convention in combination with variadicity.
"Denote" (at least the first context you use it in) doesn't quite cut it because it isn't limited to notation. The second problem I have with your proposal is, that you are choosing a difficult example before showing a simple one. "One or more" needs emphasis. 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?
When several tags for the same property appear in the argument list, only the last one is used; others are ignored.
tag<nonvariadic,variadic> // same as 'variadic'
The semantics of tag<nonvariadic, variadic> should be identical to the semantics of tag<variadic, nonvariadic>. It strikes me as erroneous that this combination of denotations would not yield a compilation error. Have you a well-founded argument for this choice?
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 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? 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.
I'm new to this thread; apologies if I'm rehashing something that was settled earlier.
No need to apologize. Your feedback is very welcome! Further some reshing is currently a good thing because there have been comparatively drastic changes. Thanks, Tobias
Tobias Schwinger wrote:
Dave Gomboc wrote:
Tag Types: ----------
The Function Type library uses tag types to represent one more attributive properties of a type, such as its variadicness or its calling convention.
"one more"? Did you mean "one or more"?
Yes. It got lost, somehow...
"a type"? It might be one type per tag, but tagging can be applied to more than one type, so this should be rephrased.
Well, not at once. It's a 1..* relation:
one type --- N tags to describe its attributes
This all can happen M times, so we have a "infinity != infinity * infinity" situation here. This is why I'm not sure if making it plural is a good here.
"variadicness"? I think you meant "variadicity".
I'm not sure "variadicity" is a word either. Sorry, I copied this from David Abrahams' proposal assuming it was correct.
I'll use "whether it is variadic" instead...
I'm not thrilled by "attributive properties" either. My discomforture with this phrase is due to its perceived redundancy. Is it common for properties to exist that attribute nothing?
I recently excluded the "decoration" property (pointer, reference,member pointer or plain function type) from this set (so "attributive" is meant as opposed to "fundamental"). I agree it's not perfect.
s/attributive properties/attributation/
I propose:
The Function Type library uses tag types to denote properties of types. For example, the tag
tag<fastcall, variadic>
may be used to denote use of the fast calling convention in combination with variadicity.
"Denote" (at least the first context you use it in) doesn't quite cut it because it isn't limited to notation. The second problem I have with your proposal is, that you are choosing a difficult example before showing a simple one.
"One or more" needs emphasis.
...and I forgot about it in the following text:
The Function Type library uses tag types to represent a type's attributation, such as its calling convention or wether it is variadic.
<- A tag encapsulates one or more properties.
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?
When several tags for the same property appear in the argument list, only the last one is used; others are ignored.
tag<nonvariadic,variadic> // same as 'variadic'
The semantics of tag<nonvariadic, variadic> should be identical to the semantics of tag<variadic, nonvariadic>. It strikes me as erroneous that this combination of denotations would not yield a compilation error. Have you a well-founded argument for this choice?
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
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?
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.
I'm new to this thread; apologies if I'm rehashing something that was settled earlier.
No need to apologize. Your feedback is very welcome!
Further some reshing is currently a good thing because there have been comparatively drastic changes.
s/resh/rehash/
participants (2)
-
Dave Gomboc -
Tobias Schwinger