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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-06-27 15:11:03

From: Tobias Schwinger <tschwinger_at_[hidden]>
> 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:
> > 
> > "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."
> 
>    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.

   When classifying types, it is often necessary to match against
   any of several aspects.  The most important case is to match
   all possibilities.  In other words, to ignore that aspect.
   That case is handled by the tag named "unspecified_" plus the
   aspect name).

   For example,

      is_function< T, unspecified_decoration >::value

   is true when T is a function, function pointer, function
   reference, or member function pointer type.

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

Is it necessary to have a name for combinations of 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).

"unbound" seems reasonable, but it is not used in C++ circles, so
it is a foreign term.  How about "free_or_static?"  it isn't as
long and "free function" is a normal term.

> >>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 ;-)

s/concretized/made concrete/

> 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).

That sentence is essentially meaningless to me.  Do you mean
something like the following?

   The effect is "as if" each of the aspects in the query set had
   been used separately and the results from each query had been
   logically OR'ed together.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;