This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ PATCH to add auto return type deduction with -std=c++1y


On Sun, 25 Mar 2012, Basile Starynkevitch wrote:

On Sun, 25 Mar 2012 12:17:10 +0200 (CEST)
Marc Glisse <marc.glisse@inria.fr> wrote:

On Sun, 25 Mar 2012, Jason Merrill wrote:

As I mentioned in my patch to add -std=c++1y, I've been working on a proposal
for the next standard to support return type deduction for normal functions,
not just lambdas.  This patch implements that proposal.

Nice. I like the way you seem to be going for the basic, uncontroversial version (extensions can always be discussed later), instead of trying to figure out something universal.

If I understand correctly, you pick the first return statement for type
deduction, and other returns (if any) are only checked afterwards for
exact consistency [...]

I am not a C++ or a GCC front-end expert, but I am not sure it is the right approach for functions starting with if (!p) return nullptr; where p is a formal argument.

Or perhaps I am misunderstanding what Marc is saying.

I would rather suggest using all the return statements to infer the type of the function,
not only the first one.

First, note that I only explained my understanding from a quick look at the testsuite examples and a couple minutes playing with it, the actual proposal may well be very different. However:


- a first goal is simple functions, with a single return statement (which may even often be the only statement).
- inferring a common type is very hard to define (std::common_type has a number of funny properties).
- since he rejects code that has several returns with different types, any kind of inference you later manage to add will be 100% compatible.


Yes, it has limitations (it is because I hit them that I guessed the "first return statement" rule), but it never does the wrong thing, at worst it rejects code that is already invalid today. I agree that inference from all returns would be great, later...

--
Marc Glisse


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]