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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-06-28 11:11:14

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

s/handled by/handled by using/

[While we're on English usage, and just in case you have or might
use it in the documentation, note that your use of "alike" above
is not idiomatically correct (in the US anyway), and I'm not
positive it is semantically correct.  "Similar" works fine as
does "the like."]

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

Pretty close:

   When classifying types it is often necessary to match against
   several variations of one aspect.  The most important case is
   to match any variation; that is, to ignore that aspect.  The
   tags named "unspecified_" plus the aspect's name describe
   these cases.

> >    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).
[snip]
> >>   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

s/semantical/semantic/

With that, it seems pretty good.

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

I don't understand the subject well enough to offer any more help
here, I'm afraid.

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