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_at_[hidden]> Gesendet:Sa 23.05.2026 14:59 Betreff:Re: [std-proposals] return value lives until end of scope An:std-proposals_at_[hidden]; CC:Andrey Semashev <andrey.semashev_at_[hidden]>; 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_at_[hidden]> >     *Gesendet:*Sa 23.05.2026 13:13 >     *Betreff:*Re: [std-proposals] return value lives until end of scope >     *An:*std-proposals_at_[hidden]; >     *CC:*Andrey Semashev <andrey.semashev_at_[hidden]>; >     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_at_[hidden] >     https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals > > -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals