Re: [boost] [function types] New tag type logic

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-27 09:33:12

John Maddock wrote:
>>The kinds of a type to be synthesised and complex classification queries
>>are
>>described by *tag* types.
>>
>>A tag encapsulates one or more aspects of the kind of type (see
>>reference).
>>
>>Tags which only encapsulate a single aspect are called *aspect tags* in
>>the
>>following text.
>>These can be used to query, whether a type's kind reflects this aspect:
>>
>>     is_function_type< T, pointer >
>>     is_function_type< T, variadic >
>>
>>Aspects can be *abstract* : In this case several non-abstract
>>possibilities of
>>the same aspect are matched for querying:
> 
> 
> I'm not sure that abstract is the right word here, I had to read right
> through this text a couple of time to understand what you're driving at
> here: more than one tag, which may be mutually exclusive in the type system.
> So maybe:

Yeah. This did not feel exactly perfect, when writing it. This sentence doesn't 
fit too well into the text flow, either -- and "aspect" and "abstract" sound very 
similar which makes it even harder to understand, I guess.

> 
> "Aspects can also be *abstract*.
> An abstract tag is the union of one or more tags, which are normally
> mutually exclusive.  They are used when querying a type, if you don't care
> which of a set of mutually exclusive options is present, for example:
> 
> is_function_type<T, unbound>::value
> 
> will be true if T is a function type, a reference to a function, or a
> pointer to a function."
> 
> This is still not terribly good English mind you!

   When classifying types, it is often neccessary to match supersets of
   possibilities for one aspect:

   The most important case is to match all possibilities which means in fact to
   ignore that aspect (the names of the corresponding aspect tags are prefixed with
   "unspecified" for this case).

     is_function< T, unspecified_decoration >::value

   is true for T being a function, function pointer, function reference and member
   function pointer type.

Does this read better (it's still incomplete)? Can we call them "super aspects"?

> 
> I also don't like the use of "unbound" here, the name doesn't mean anything
> to me.  I see later on you have "unspecified_decoration", is this the same
> meaning?  If so I very much prefer the latter.

"unbound" wants to mean "freestanding_or_static" (which is a bit lengthy).

> 
> 
>>Abstract tag aspects are concretized (see refernce) when used for type
>>synthesis:
> 
> 
> I don't think "concretized" is actually a word, but I know what you mean ;-)

I tried to get around overloading the term "default" once another time...

   When super aspects are encountered during type synthesis, the behaviour is
   the same as for one of its specializations by definition (see reference).

> 
> Maybe someone has a better suggestion?
> 

Still welcome, of course!

> This is definitely going in the right direction IMO.
> 

Thanks again,

Tobias