Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Thu, 29 Mar 2012, Marc Glisse wrote:
On Wed, 28 Mar 2012, Marc Glisse wrote:
On Sun, 25 Mar 2012, Marc Glisse wrote:
- a first goal is simple functions, with a single return statement (which
may even often be the only statement).
After playing with it a bit, I am not sure how to use it in the simple
forwarding case:
T f(int);
auto g(int i){return f(i);}
If T is a reference, this does a copy.
auto&& g(int i){return f(i);}
Now if T is not a reference, this returns a reference to a destroyed
temporary.
I haven't given this idea much thought, but here goes:
The main issue seems to be that "auto&&" deduction gives a dangerous unusable
answer on a temporary. Well, let's change that to make the deduction be the
same as plain "auto" in that case (how different does that make it from
decltype?). Sure, it requires some more complicated wording. But to users, it
could actually be more intuitive as auto&& would remain a do-what-I-mean
perfect forwarder. And plain "auto" would remain compatible with lambdas.
Hmm, the fact that this doesn't fit the usual "deduce auto and collapse
references with &&" model might make it unacceptable, although it would be
more useful than rejecting (or strongly warning against) the code for
temporaries.
Oh well, the current proposal is useful as is, and there is probably room
left if we later want to add a syntax that implies decltype deduction
(decltype(auto)? decltype without parenthesis?).
--
Marc Glisse
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Wed, 28 Mar 2012, Marc Glisse wrote:
On Sun, 25 Mar 2012, Marc Glisse wrote:
- a first goal is simple functions, with a single return statement (which
may even often be the only statement).
After playing with it a bit, I am not sure how to use it in the simple
forwarding case:
T f(int);
auto g(int i){return f(i);}
If T is a reference, this does a copy.
auto&& g(int i){return f(i);}
Now if T is not a reference, this returns a reference to a destroyed
temporary.
I haven't given this idea much thought, but here goes:
The main issue seems to be that "auto&&" deduction gives a dangerous
unusable answer on a temporary. Well, let's change that to make the
deduction be the same as plain "auto" in that case (how different does
that make it from decltype?). Sure, it requires some more complicated
wording. But to users, it could actually be more intuitive as auto&& would
remain a do-what-I-mean perfect forwarder. And plain "auto" would remain
compatible with lambdas.
--
Marc Glisse
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Wed, 28 Mar 2012, Jason Merrill wrote:
On 03/28/2012 03:20 PM, Marc Glisse wrote:
I agree that it works like initialization, and like lambdas, so that
ship has sailed. I assume there were good reasons for that, even if they
are not obvious, I know things can be trickier than they appear.
However, I can't help thinking that there is something wrong with having
to write:
auto g(int i) -> decltype(f(i)) { return f(i); }
I agree that this is a serious problem; decltype has the semantics we want,
and so new functionality that does something different may not actually be
very useful.
It seems useful to have return type deduction while still being able to
say: "return by value" or "return const" or "return an lvalue reference",
which your change provides.
Unfortunately, making auto functions different from auto
variables and lambdas isn't very appealing, either.
Especially lambdas, yes (in N1968, lambdas were supposed to use decltype
for their return type, it was changed later in the process, I'll have to
try and find that discussion).
Making them different from auto variables seems quite natural, the
situations are really different.
--
Marc Glisse
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On 03/28/2012 03:20 PM, Marc Glisse wrote:
I agree that it works like initialization, and like lambdas, so that
ship has sailed. I assume there were good reasons for that, even if they
are not obvious, I know things can be trickier than they appear.
However, I can't help thinking that there is something wrong with having
to write:
auto g(int i) -> decltype(f(i)) { return f(i); }
I agree that this is a serious problem; decltype has the semantics we
want, and so new functionality that does something different may not
actually be very useful. Unfortunately, making auto functions different
from auto variables and lambdas isn't very appealing, either.
Jason
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Wed, 28 Mar 2012, Gabriel Dos Reis wrote:
On Wed, Mar 28, 2012 at 10:51 AM, Marc Glisse wrote:
On Sun, 25 Mar 2012, Marc Glisse wrote:
- a first goal is simple functions, with a single return statement (which
may even often be the only statement).
After playing with it a bit, I am not sure how to use it in the simple
forwarding case:
T f(int);
auto g(int i){return f(i);}
function call or return value is equivalent to initialization. So, the
deduction works (as it should) as if you wrote
auto x = f(i);
I agree that it works like initialization, and like lambdas, so that ship
has sailed. I assume there were good reasons for that, even if they are
not obvious, I know things can be trickier than they appear. However, I
can't help thinking that there is something wrong with having to write:
auto g(int i) -> decltype(f(i)) { return f(i); }
(and even worse with noexcept(noexcept(f(i))), but that's another issue)
for a simple macro-like forwarding function.
Now fixing that isn't the goal of Jason's proposal and this is fine.
--
Marc Glisse
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Wed, Mar 28, 2012 at 10:51 AM, Marc Glisse wrote:
> On Sun, 25 Mar 2012, Marc Glisse wrote:
>
>> - a first goal is simple functions, with a single return statement (which
>> may even often be the only statement).
>
>
> After playing with it a bit, I am not sure how to use it in the simple
> forwarding case:
>
> T f(int);
> auto g(int i){return f(i);}
function call or return value is equivalent to initialization. So, the
deduction works (as it should) as if you wrote
auto x = f(i);
>
> If T is a reference, this does a copy.
>
> auto&& g(int i){return f(i);}
>
> Now if T is not a reference, this returns a reference to a destroyed
> temporary.
>
> So I am back to writing the following, which is precisely what we never want
> to write:
>
> auto g(int i)->decltype(f(i)){return f(i);}
>
> Maybe having just auto (no auto const&, auto&& and others) without stripping
> cv-ref from it would work better in this case? It would have drawbacks in
> other cases...
>
> I guess the discussion should happen on a different forum once the proposal
> is published...
>
> --
> Marc Glisse
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Sun, 25 Mar 2012, Marc Glisse wrote:
- a first goal is simple functions, with a single return statement (which may
even often be the only statement).
After playing with it a bit, I am not sure how to use it in the simple
forwarding case:
T f(int);
auto g(int i){return f(i);}
If T is a reference, this does a copy.
auto&& g(int i){return f(i);}
Now if T is not a reference, this returns a reference to a destroyed
temporary.
So I am back to writing the following, which is precisely what we never
want to write:
auto g(int i)->decltype(f(i)){return f(i);}
Maybe having just auto (no auto const&, auto&& and others) without
stripping cv-ref from it would work better in this case? It would have
drawbacks in other cases...
I guess the discussion should happen on a different forum once the
proposal is published...
--
Marc Glisse
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Sun, Mar 25, 2012 at 8:32 AM, Marc Glisse wrote: > - a first goal is simple functions, with a single return statement (which > may even often be the only statement). yes, this is something we tend to forget: simple things should stay simple, no matter how clever we think we can get. for that reason, I like the approach. -- Gaby
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 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
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Sun, 25 Mar 2012 12:17:10 +0200 (CEST)
Marc Glisse 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.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: C++ PATCH to add auto return type deduction with -std=c++1y
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, which simplifies the problem quite a bit while still allowing some recursion (although interestingly, constexpr functions require the use of a single return with ?: whereas your auto functions prefer an if and several returns). Naturally, auto functions have to be instantiated a bit more eagerly than regular functions, and there is no try to sfinae the auto deduction. That seems to fit many simple functions quite nicely with little room for unintended consequences. I tried to send this message before with the proposal attached in HTML, but the mailing list rejects HTML attachments, so I've dropped it. I'm happy to send it separately to anyone interested. I guess I'll have plenty of chances to look at it once it is submitted (it isn't like I'd have much to contribute...). -- Marc Glisse
