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_at_[hidden]>
wrote:

> Send Std-Discussion mailing list submissions to
> std-discussion_at_[hidden]
>
> 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_at_[hidden]
>
> You can reach the person managing the list at
> std-discussion-owner_at_[hidden]
>
> 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_at_[hidden]>
> To: std-discussion_at_[hidden]
> Subject: [std-discussion] named function return value
> Message-ID:
> <CAPXH1mvZD=H-GxdaW17ZNQkXcHsah4oRn5bF=D=
> aXoFxp-Ba_Q_at_[hidden]>
> 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_at_[hidden]>
> To: std-discussion_at_[hidden]
> Subject: Re: [std-discussion] named function return value
> Message-ID:
> <CANLtd3WkZwJotzP_QU3i7Ctksqor=C=
> VJBosbXRjVimtFi-2Vg_at_[hidden]>
> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
>
> ------------------------------
>
> End of Std-Discussion Digest, Vol 37, Issue 2
> *********************************************
>