A part of my message seems to have been deleted without me noticing. Sorry.

It should have been something like: If the inner code blocks can be cleanly separated and only write to var,

Yes, it is feasible only sometimes.

But perhaps it helps to find a clean solution within the C++ philosophy.

There are also do expressions (P2806) with do_return in a similar vein.

Is a local std::optional<> so bad? It (the overhead) can be optimized away and clearly states the intent.

-----Ursprüngliche Nachricht-----
Von: Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Sa 23.05.2026 14:59
Betreff: Re: [std-proposals] return value lives until end of scope
An: std-proposals@lists.isocpp.org;
CC: Andrey Semashev <andrey.semashev@gmail.com>;
On 23 May 2026 14:56, Sebastian Wittmeier via Std-Proposals wrote:
> If the inner code blocks just create var, a separate function or a
> lambda can handle it with its return value.
>
> Then auto can be used (twice, for the return type and the variable type).

I'm not sure I understand what you're describing, but if you mean
extracting the body of the `if` statement into a function or lambda then
this isn't always feasible as it's often too tied with the rest of the
context of the enclosing function. And extracting a random piece of code
into a function that doesn't make sense on its own is hardly a desirable
solution.

>     -----Ursprüngliche Nachricht-----
>     *Von:* Andrey Semashev via Std-Proposals <std-
>     proposals@lists.isocpp.org>
>     *Gesendet:* Sa 23.05.2026 13:13
>     *Betreff:* Re: [std-proposals] return value lives until end of scope
>     *An:* std-proposals@lists.isocpp.org;
>     *CC:* Andrey Semashev <andrey.semashev@gmail.com>;
>     On 23 May 2026 10:36, Frederick Virchanza Gotham via Std-Proposals
>     wrote:
>     > On Thursday, May 21, 2026, Jonathan Wakely wrote:
>     >
>     >     Yeah, I don't want spooky changes to the lifetime model and how it
>     >     interacts with scopes to happen implicitly based on something far
>     >     away on the function declaration. If somebody adds
>     __persistent to a
>     >     declaration, it silently changes the meaning of existing
>     callers. No
>     >     thanks.
>     >
>     > What if we were to move the 'mark' to the calling site. Perhaps a
>     unary
>     > operator? So the following:
>     >
>     >     int main(void)
>     >     {
>     >         %async(Func);
>     >     }
>     >
>     > would be the same as:
>     >
>     >     int main(void)
>     >     {
>     >         auto dummy = async(Func); 
>     >     }
>
>     While I do not like the unary % idea (because all of the implicitness
>     and ambiguity with loops, and because it doesn't actually solve the
>     originally stated problem with std::async), I think there are cases
>     where one would want to declare a variable in an outer scope, where the
>     `auto _` approach doesn't quite work. The following pattern comes up
>     quite often:
>
>      type var = ???;
>      if (condition1)
>      {
>        auto inner_var = do_bunch_of_stuff();
>        if (condition2(inner_var))
>          var = compute_var();
>      }
>
>      use_var(var);
>
>     Here, `type` may not always be possible to shortcut as `auto`, if the
>     initializer is not easy to produce. So one has to spell out the type
>     explicitly.
>
>     The other problem is, obviously, var's initializer and handling the case
>     of var being not initialized in the nested scope. You would typically
>     use a sentinel value for the initial initializer or std::optional, but
>     the former is not always possible and the latter requires an include and
>     has runtime overhead.
>
>     I'm not necessarily proposing a solution, but just stating that there is
>     a use case for out-of-scope variable declaration that could benefit from
>     core language support.
>
>     --
>     Std-Proposals mailing list
>     Std-Proposals@lists.isocpp.org
>     https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>

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