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
On 14.10.2010 02:09, Matt Calabrese wrote:
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 is definitely a bug somewhere.
Specifically, it is a bug in GCC, because the standard says in [basic.lookup.unqual]p8: "A name used in the definition of a member function of class X following the function's declarator-id [....] shall be declared in one of the following ways: [...] - shall be a member of class X or be a member of a base class of X [...]" The trailing return type in a member function definition is part of the definition and is after the declarator-id, so the paragraph applies. Furthermore, the lookup rules don't make a distinction between different kinds of members. Sebastian
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:
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
On Wed, Oct 13, 2010 at 8:09 PM, Matt Calabrese <rivorus@gmail.com> 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 Please be sure to provide the test machinery. See http://tinyurl.com/2afubs9 Thanks, --Beman
participants (4)
-
Beman Dawes -
David Abrahams -
Matt Calabrese -
Sebastian Redl