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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-27 16:36:06

Rob Stewart wrote:
> 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).
> 

It reads nice. But needs semantical adjustment:

It's not about matching "several aspects" (that's what the combination of aspect 
tags is for) but about matching several possibilities of the very same aspect, 
otherwise I'ld have to change the definitions of the terms.

=> s/several aspects/the possibilties of one aspect/
=> => s/all possibilties/all of them/ (so "possibilties" does not repeat)

Further tags don't really "handle" things -- they are just data. "Describe" (or 
alike) would be better in this context.

In a whole:

     When classifying types, it is often necessary to match against
     several possibilities of one aspect.
     The most important case is to match all of them.  In other words,
     to ignore that aspect. The tags named "unspecified_" plus the aspect
     name describe these cases.

Still clear enough?

>    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?
> 

It's helpful (see below).

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

Agreed.  => s/unbound/free_or_static/g

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

No. It's about what happens when an abstract tag (or whatever we call it) is used 
to describe a type to be created:

     An abstract tag has a non-abstract semantical equivalence when used in the
     context of type synthesis

(as annotated in the reference draft of the original post).

I've currently no idea how to say this without the "abstract" term, though.

Thank you for helping,

Tobias