Re: [boost] C++0x trailing return type

Subject: Re: [boost] C++0x trailing return type
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-14 05:37:06

At Wed, 13 Oct 2010 20:09:10 -0400,
Matt Calabrese wrote:
> 
> 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?

+1

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

Ouch!  It doesn't surprise me too much, but I'm outraged too.  Please
write up an issue and post it to comp.std.c++!

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

If the standard doesn't allow it, it's forbidden :-(

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

I think you'd need to write a paper and get it done before Monday if
you wanted to have any hope.  If you can come to Batavia, that'd be
great too, but otherwise, I'll champion it for you.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com