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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-06-30 08:52:34

From: Tobias Schwinger <tschwinger_at_[hidden]>
> 
>     Tag types:
>     ----------
> 
>     The kinds of a type to be synthesised and complex classification queries are

I don't understand "the kinds of a type."  Is this a reference to
something discussed elsewhere?  If so, reference that discussion.
If not, clarify here.

>     described by *tag* types.

No paragraph break here.

>     A tag encapsulates one or more aspects of the kind of type.

s/kind/kinds/ to be consistent with the first sentence?  (I still
don't understand the phrase, though.)

>     Tags which only encapsulate variations of a single aspect are called

s/only encapsulate/represent the/ ?

>     *aspect tags* in the following text (see reference).

Strike "in the following text."  You're creating the term for the
library, not just the following text.

>     Aspect tags can be used to query, whether a type's kind reflects this aspect:

No comma.  s/reflects/includes/ or s/reflects/is described by/ ?

>          is_function< T, variadic >
>          is_function< T, pointer >  // same as is_function_pointer<T>
> 
>     When classifying types it is often necessary to match against several
>     variations of one aspect. There are special variations which make this
>     possible. These are called *abstract variations*.

   There are special tags that represent groups--or the union--of
   several variations of a single aspect.

Shouldn't "abstract variations" be "abstract tags?"

I think, like John suggested, that "composite tags" works better
than "abstract tags."  The special variation you use represents a
grouping or union of variations, not a generalization of them.

>          is_function< T, free_or_static >
> 
>       The free_or_static describes an abstract variation of the decoration aspect
                          ^tag

>       and makes the above code is equivalent to:

s/is //

>          mpl::or_< is_function_type< T, undecorated>
>                  , is_function_type< T, pointer>
>                  , is_function_type< T, reference> >
> 
>     An important use case for abstract variations is to match any variation of an
>     aspect; that is, to ignore it in the context of type classification. Because of
>     this, every aspect has at least one abstact variation, described by the

s/abstact variation/abstract tag/ (or "composite tag" ;0)

>     (aspect) tag named "unspecified_" plus the aspect name.

Instead of "unspecified_" how about "any_?"  It is shorter and
fits the prose.  Whenever you discuss this, you refer to matching
*any* variation.

>          is_function< T, unspecified_decoration >::value
>          // true for any type T the library can handle

You said my version was incorrect because I suggested this query
was only useful in combination with other queries.  I don't see
the point in asking whether a type fits any variation of an
aspect while asking about no other aspects.  In that case, you're
asking about no aspects.  The above suggests that one might have
to choose an "any" aspect tag just to ask whether a type is a
function type, but that just seems messy. So, what are the use
cases for a query like the above in which nothing specific is
queried?

>     Each abstract variation of an aspect has a non-abstract semantical equivalence

s/semantical/semantic/

I like the "non-abstract semantic equivalence" phrasing to
explain the "concrete" usage of the tags.

>     when used in the context of type synthesis (as defined in the reference
>     section):
> 
>          function_type<void(X::*)(), free_or_static>::type
> 
>       is equivalent to:
> 
>          function_type<void(X::*)(), undecorated>::type

That use of free_or_static seems just plain wrong.  Why would you
synthesize a type while giving a choice as to how it is
decorated?  Yes, you can document that free_or_static and
undecorated are the same in this context, but it is confusing at
best.

>     When a tag is taken from a type, the resulting tag explicitly describes all
>     aspects, none of them with an abstract variation:

   When querying for a tag describing a type, the result is a
   nonabstract tag that describes all aspects of the type.

Yours was structured poorly, but more importantly, I didn't get
the "taking" a tag from a type part.  I'm sure mine doesn't
capture the concept quite right, but hopefully it helps.

>          signature< void() >
> ANNOTATION: ^^^ will be a model of Tag (this is not yet documented)
>          // describes all aspects: undecorated, non-variadic, ...
> 
>     When classifying and especially when synthesising types, there are situations
>     where it is neccessary to describe more than one aspect. Therefore tags can be

s/where/in which/ (situations aren't places)

>     combined.

   combined in a single query using the tag metafunction.

>     E.g. for synthesising a both variadic and pointer-decorated function:

FWIW, I always find it appropriate to follow "for example" with a
comma, so I consider it approprite to follow "e.g." with one.

>          function_type< mpl::vector<int,int>, tag<pointer,variadic> >::type
> 
>     In classification context all aspects in the query tag must match:

s/context/contexts/

>          is_function_type< void(...), tag<free_or_static,variadic> >::value
>          // is true
> 
>          is_function_type< void(X::*)(...), tag<free_or_static,variadic> >::value
>          // is false
> 
>     When the 'tag' metafunction is used to combine tags, which describe different

No comma.

>     variations of the same aspect, the right hand side tag's variation is used --
>     it *overrides* the aspect:

Try this instead:

   When using the tag metafunction to combine tags, it is
   possible to have different variations of the same aspect in
   the list.  In that situation, the last (rightmost) variation
   is used; the others are ignored.

>          tag<free_or_static,reference>
>          // decoration aspect is 'reference'
> 
>          tag<reference,undecorated>
>          // decoration aspect is 'undecorated'
> 
>          tag<undecorated,reference,undecorated>
>          // decoration aspect is 'undecorated'
> 
>     Tag combination occurs either explicitly by using the 'tag' metafunction or
>     implicitly when using 'function_type' with an optionally decorated function
>     type or a tag as its first template argument:

   Tag combination occurs either explicitly, by using the tag
   metafunction, or implicitly.  Implicit tag combination occurs
   when using function_type with a tag or a (possibly decorated)
   function type as its first template argument.

>          function_type<void __cdecl(X::*)(),tag<undecorated,unspecified_call> >
>          // ::type member is 'void(my_class&)'
>          // the decoration and calling convention aspect are overridden
> 
>     Aspect tag reference:
>     ---------------------
> 
> ANNOTATION: a proper explanation for "(default)" is still missing, please ignore 
> it for now.
> 
>       // - decoration aspect
>       typedef /.../ unspecified_decoration; // (*) (default)

any_decoration

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

any_variadic

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

any_constness

>       typedef /.../ const_;
>       typedef /.../ non_const;
>       // (*) abstract - same qualfication as the class type when used for synthesis
> 
>       // - volatile aspect
>       typedef /.../ unspecified_volatility; // (*) (default)

any_volatility

>       typedef /.../ volatile_;
>       typedef /.../ non_volatile;
>       // (*) abstract - same qualfication as the class type when used for synthesis
> 
>       // Calling convention aspect
>       typedef /.../ unspecified_call; // (*) (default)

any_call

>       typedef /.../ cdecl, stdcall, etc. (depends on configuration)
>       // (*) abstract - uses the default calling convention when used for synthesis

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