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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-28 14:36:19

David Abrahams wrote:
> Tobias Schwinger <tschwinger_at_[hidden]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>True for the second version, for the first (and the latest, parallel to you post 
>>in this thread) there is "one aspect" in the preceding sentence. Is it too far away?
> 
> 
> Well, it appears visually to be in a separate paragraph, so yes.  

Ah, good point! I'll remove the line break.

> 
> 
>>>Also, the text there beginning with "In other words," and ending with
>>>a period is not a complete sentence.
>>
>>Will it become a valid subordinate clause if we change the period before it to a dash?
>>
>>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.
>>
>>Does this work?
> 
> 
> Better.  Does this documentation really define what a "possibility of
> an aspect" is?  If not, you had better do so, or better yet, pick more
> understandable and evocative terminology.
> 

I'll use the term "variation" instead of "possibility" (as just proposed by Rob 
Stewart):

     Tag types:
     ----------

( changes: "variations of" inserted, corrected misplaced "(see reference)" )

     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.

     Tags which only encapsulate variations of a single aspect are called
     *aspect tags* in the following text (see reference).

                                               ^^^
                                             links to:

     Aspect tags:
     ------------

      // - decoration aspect
      typedef /.../ unspecified_decoration; // (*) (default)
      typedef /.../ unbound; // (*) (matches the next three)
      typedef /.../ undecorated;
      typedef /.../ pointer;
      typedef /.../ reference;
      typedef /.../ member_pointer;
      // (*) abstract - same as 'undecorated' when used for synthesis

      // - variadic aspect
      typedef /.../ unspecified_variadic; // (*) (default)
      typedef /.../ non_variadic;
      typedef /.../ variadic;
      // (*) abstract - same as 'non_variadic' when used for synthesis
      ...

Does it work?!

Thanks,

Tobias