C++0x trailing return type

14 Oct 2010

      I'd like to introduce a macro to Boost.Config
called BOOST_NO_TRAILING_RETURN_TYPE for checking if a compiler supports 0x
trailing return types I.E.

auto foo() -> void;

Is there general agreement that this is an appropriate name for the macro?

Now for a small rant -- in a recent thread, I talked about introducing a
simple BOOST_AUTO_FUNCTION macro which I'll request review for shortly, as a
way to simulate automatic return type deduction when writing functions and
function templates. In experimenting with the macro, I have hit what I
believe is either a bug in GCC or what I would consider a huge failing of
C++0x trailing return types (someone please aid me in figuring this
out). One of the main reasons why trailing return types are helpful is that
the arguments to the function or function template you are writing are able
to be refered to when forming the return type, however, when dealing with
non-static member functions, it seems to me that you are not able to refer
to "this" or non-static members. This greatly reduces the usefulness of
trailing return types, as all of the reasons why you would want to refer to
the parameters apply with the same rationale to why you would want to refer
to members and "this". I've skimmed through the standard and see no explicit
mention of or examples of using trailing return types in this manner.
Perhaps someone here can help parse the standard-ese to clarify? I'd hope
that you could refer to non-static members, but I see no evidence of that.

One example of why this is frustrating in practice can be seen in the
following hypothetical code for a Boost.Variant-style template with an
"emplace" member-function that is intended to construct an object in-place
similar to the emplace family of member functions of C++0x containers:

http://codepaste.net/u5nfis

Here, the trailing return type is used almost exclusively for extended
SFINAE, though you often wish to refer to members in other cases as well
where SFINAE isn't of any concern. The overall goal with the implementation
of emplace being as such is to attempt to force substitution to fail if any
of the following cases were true:
if "Type" does not have a constructor taking the forwarded arguments
if "Type" is not one of the types that is able to be stored in the template
and possibly even something else I've missed (...which is a good thing...)

Essentially we want substitution to fail if the instantiation of the body
would fail, giving a very basic equivalent to low-level, syntax-only,
automatic concept-checking. The benefit of this speaks for itself. Here, at
least in my opinion, such code is very concise, very powerful, and
surprisingly readable. Without such functionality of trailing return types
we can only do marginally better than we've been doing for the past 10
years.

So if someone could help me determine whether or not what I'm trying to do
is standard I'd be grateful, and if such functionality is not standard, is
it too late for it to be added? It seems to me that the benefits with
respect to library development here are too great for a community like Boost
to ignore, though I myself am not familiar enough with the standardization
process to make an impact. Thanks.

It appears this rant has overshadowed the original question, though please
don't forget to respond.

-- 
-Matt Calabrese

Matt Calabrese

Sebastian Redl

David Abrahams

Beman Dawes

tags

participants (4)