Thanks for the correction. I'll ask in the std-proposal ML.

As for your comment, my idea was that the rest of the function behaves the same.
You just get a compiler-generated declaration at the top and a return at the bottom.
You can still do early return like this:
```
auto func() -> int ret{}
{
  ret += 5;
  if(something)
    return ret;

  ret += 10;
}
```
Also, you can return other values, not just the declared one:
```
auto func() -> int ret{}
{
  ret += 5;
  if(something) return 42;
}
```

As for the coroutines, you're right, it complicates things a bit.


On Sun, Apr 3, 2022 at 3:00 PM <std-discussion-request@lists.isocpp.org> wrote:
Send Std-Discussion mailing list submissions to
        std-discussion@lists.isocpp.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
or, via email, send a message with subject or body 'help' to
        std-discussion-request@lists.isocpp.org

You can reach the person managing the list at
        std-discussion-owner@lists.isocpp.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Discussion digest..."


Today's Topics:

   1. named function return value (?????? ??????)
   2. Re: named function return value (F.v.S.)
   3. Re: named function return value (Jason McKesson)


----------------------------------------------------------------------

Message: 1
Date: Sat, 2 Apr 2022 15:06:07 +0300
From: ?????? ??????  <zamfir.yonchev@gmail.com>
To: std-discussion@lists.isocpp.org
Subject: [std-discussion] named function return value
Message-ID:
        <CAPXH1mvZD=H-GxdaW17ZNQkXcHsah4oRn5bF=D=aXoFxp-Ba_Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I'm not sure if this is the right place or the right way to ask but I was
wondering if there is a (similar) proposal for the following:

Adding an explicit name and an initial value to the return value of a
function.
I imagine the following function signature (in pseudocode) :

auto func_name(Type1 arg1, Type2 arg2, etc.) -> RetType *ret_value_name
> {init_value}*;
>

The change from existing code is the addition of a name after the return
type and an initialization.
Think of the initialization as a default value.

I've noticed a lot of cases where a programmer would write functions like
this:

int vector_sum(const std::vector<int>& vec) // or auto sum(const
> std::vector<int>& vec) -> int
> {
> *  int result = 0;*
>   for(const auto value : vec) result += value;
> *  return result;*
> }
>

The *bolded* lines are repeated in many functions which return a new object
constructed or built from the function arguments.

I imagine with this new syntax these lines would be implicitly generated by
the compiler.
So, the function above can be written like this:

auto vector_sum(const std::vector<int>& vec) -> int result {0}
> {
>   for(const auto value : vec) result += value;
> }


I was inspired by Ben Deane's talk at CppCon2021 about adding an explicit
type to the 'this' argument.
This is a similar idea but related to an explicit name of the return value.

Some clarifications:

As far as I can tell the initialization is required because if it's
optional the compiler won't be able to tell if the curly braces belong to
the initialization or the function body.
So, if the compiler sees an identifier after the return type it should
always expect an initializer before the function body (or before the
semicolon for function declarations).
If it doesn't see an identifier after the return type it should expect the
function body straight away (how it is now).

For function declarations (without a body) if you don't need (or you
cannot) provide an initial value, you should not provide an explicit return
value name.
So it's either both a name and an initialization or none.
Then in the actual definition you can provide the name and the initial
value.
Similarly to how currently you can omit the argument names in function
declarations and then provide them in the definition.

The usage of curly braces in the initialization also doesn't cause problems
with pure virtual function declarations.
For example:

> virtual auto func(int arg) -> int result {10} = 0;
>
Although, in most cases I don't think you would need an explicit return
value name in pure virtual functions.

What do you think about this idea?
Has anyone proposed something like this?

Best regards,
Zamfir Yonchev
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

[Message discarded by content filter]
------------------------------

Message: 3
Date: Sat, 2 Apr 2022 10:59:30 -0400
From: Jason McKesson <jmckesson@gmail.com>
To: std-discussion@lists.isocpp.org
Subject: Re: [std-discussion] named function return value
Message-ID:
        <CANLtd3WkZwJotzP_QU3i7Ctksqor=C=VJBosbXRjVimtFi-2Vg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

This is the wrong place for talking about language changes. Those are
discussed in the std-proposal ML.

In any case, there are several problems.

The first problem is that it looks really *weird*. A variable is
declared outside of the function scope, and is returned from outside
of it, but all modifications are within it. That just looks strange.
To remember what the function is returning, you have to go back to the
function header. Also, functions that return values with no return
statement are broken, and programmers should be suspicious of them.
But your proposal effectively "fixes" such code, making it much easier
to accidentally write a function that doesn't return correctly.

Second, if you need to return from multiple places, you have to go
back to the old pattern. If people start liking the new pattern,
people will be encouraged to do things like this to avoid explicit
`return` statements:

```
auto func() int ret{}
{
  ret += 5;
  if(something)
    goto leave;

  ret += 10;
  leave:
}
```

That's not good.

Next, it doesn't work with coroutines and `co_return`.

Let's not make walking off the end of a function implicitly return things.


------------------------------

Subject: Digest Footer

Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion


------------------------------

End of Std-Discussion Digest, Vol 37, Issue 2
*********************************************