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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-30 05:35:29

Since the discussion seems to be drifting apart, I tried to bundle it by applying 
its results.

Please try to reply to make suggestions based on this version, so we don't waste 
too much energy on redundant work.

Thanks,

Tobias

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

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

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

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

         is_function< T, free_or_static >

      The free_or_static describes an abstract variation of the decoration aspect
      and makes the above code is equivalent to:

         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
    (aspect) tag named "unspecified_" plus the aspect name.

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

    Each abstract variation of an aspect has a non-abstract semantical equivalence
    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

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

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

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

         function_type< mpl::vector<int,int>, tag<pointer,variadic> >::type

    In classification context all aspects in the query tag must match:

         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
    variations of the same aspect, the right hand side tag's variation is used --
    it *overrides* the aspect:

         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:

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

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

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

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