Re: [boost] [function_type] Tag types documentation

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-03 06:31:26

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/