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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-06-30 14:05:39

From: Tobias Schwinger <tschwinger_at_[hidden]>
> Rob Stewart wrote:
> > From: Tobias Schwinger <tschwinger_at_[hidden]>
> > 
> >>    Tag types:
> >>    ----------
> >>
> >>    The kinds of a type to be synthesised and complex classification queries are
> 
> Here's a typo: it should be either "kinds of types" or "kind of a type".

Based upon your explanation below, it's the latter.

> > I don't understand "the kinds of a type."  Is this a reference to
> > something discussed elsewhere? 
> 
> "Elsewhere" is work in progress ;-). Here's a (maybe still bad) defintion:
> 
> A type supported by this library is completely described by its subtypes and its 
> kind. The kind collectively refers to the following information:
> - decoration (none,pointer,reference,member pointer)
> - variadicity
>    ^^^^^^^^^^^
> ANNOTATION: is this a word? Is it "variadicness" (sounds even stranger)?

Well, I don't find "variadic" in my dictionary.  My guess is that
word was coined, so if you need a noun form of "variadic," you'd
have to invent that, too.  OTOH, you could rephrase:

   - whether the function is variadic

> - cv-qualification of member function pointers
> - the calling convention attribute

Excellent.  Now I understand.  With a link from "kind of type" to
this description, it should work fine.

> >>    described by *tag* types.
> > 
> > No paragraph break here.
> 
> OK - but why?

A paragraph is to be a cohesive set of sentences that posit and
support a thesis.  A proper paragraph is rarely a single
sentence, though it certainly can be.  In this case, the
separated sentence simply amplifies on the information of those
in the previous paragraph.

> >>    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.)
> 
> Caused by that &#^$% typo above, I guess...

   A tag encapsulates one or more aspects of a type's kind.

> >>    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/ ?
> 
> OK. How about "contains"?

That's fine, but I think "includes" works a bit better--it
doesn't conjure up container semantics to me.

> >>         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?"
> 
> Don't think so: "aspects" and "variations" are semantics, the tags are their 
> syntactical encapsulation.

Here you go again!  I looked it up and was surprised to find that
"syntactical" is a recognized variant of "syntactic." ;-)
Nevertheless, I suggest "syntactic" rather than "syntactical."

Anyway, as you say, "variations" are semantic, not syntactic
elements.  Thus, they aren't concrete by definition, right?  The
groups covered by a single tag are just that -- groups or
combinations of tags.  Trying to give that a name seems misguided
unless it is a compound name like "variation set."

> > 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.
> 
> I'm afraid it /is/ in fact a generalization - see 
> http://lists.boost.org/boost/2005/06/29472.php

In that message, even you said you weren't convinced.  I disagree
with your analysis for the reasons stated.  "Unspecified
decoration" is not an abstraction or generalization of
reference-decorated.  It is a union of reference-decorated and
the others.

> >>    (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
> 
> Not sure here:
> 
>      function_type< mpl::single_view<int>, unspecified_call >::type
> 
> == "give me a function type of the default calling convention (the one you get 
> when you /don't specify/ it)"
> 
>      function_type< mpl::single_view<int>, any_call >::type
> 
> == <just strange>
> 
> I do like the shortening, though.

Your version says, "Give me a function type of whatever calling
convention you like, I don't care which one you choose," to me.
So does mine.  However, I raised that as an issue elsewhere
anyway.

> > 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?
> > 
> 
> If no second template argument is given, is_function asks for a "function type"; 
> that is as defined by the standard, "undecorated":
> 
>      template<typename T, typename Tag = undecorated> struct is_function;
> 
> Well, technically I could've used some "null tag" here, but it's more expressive 
> to say what we want, isn't it?

That says you want to know if T is an undecorated function
(whatever that is), not one with any of the recognized
decorations.  A "dont_care," "unused," or similar tag would say
what you suggested it says now.

> >>    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.
> 
> Imagine this case:
> 
>    function< typename function_type<MemFnPtr, free_or_static>::type >
> 
> I think it does make sense to express 'free_or_static' (== "remove the member 
> pointer, please") instead of 'undecorated', here.
> 
> It's not about giving a choice to the library how things are done but giving a 
> choice to the user to differently express things in different contexts. Further 
> fail-safeness has some advantages.
> 
> Remember btw. that the "_or_" in the name "free_or_static" does not reflect 
> technical distinction but only exists in terminology. That's why I initially used 
> "unbound" instead of "free_or_static".

I was using that as an example because it was before me at the
time.  You're right that free functions and static member
functions have the same function type, so this works as written.
I was actually thinking about the examples I've seen in which you
use the "unspecified" tags to pick up a default.  I'm sorry I
confused things.

As to your point that "free_or_static" is better than
"undecorated" in this case.  I disagree.  They are at least
equivalent, and having one less tag to remember is better.  After
all, your library will have to choose one to report as part of a
type's kind, so a client might not choose to use the one the
library chooses, so that client will need to know both.

> >>    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.
> 
> Inspired by "taking the address of an object" -- but you're right -- there is a 
> serious flaw: the tag is not a property of the type.
> 
> Either s/tag/kind/ or s/taking/creating/ fixes it. I prefer the former.

Only the former fits your text, and you didn't say whether you
liked my version, so I'm not certain what you mean to be the
result of the changes.  Here's another stab that might be more
accurate, and is certainly more succinct:

   The tags in a type's kind are explicit, not abstract.

> >>    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.
> 
> OK. ... and probably spell it out. Looks nicer, I guess.

You can spell it out if you like, but "e.g." is ubiquitous.

> >>    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
> 
>    ^^ "in the tags in the list" to be correct - note: syntax vs. semantics.
> 
> After applying this correction I don't find it too appealing...

I agree.  It's the wrong correction.  See below.

> What is wrong with the original in your opinion??

OK, here's your original:

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

These are some things I don't like about it:

- passive voice ("is used to");
- doesn't spell out the case for this situation as mine attempts;
- there is no "right hand side tag" if the list is broken across
  lines (I should have resisted the temptation to add "rightmost"
  to my version, but I didn't);
- uses "overrides" versus "ignored" which introduces an unneeded
  term.

Here's another try:

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

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