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
>
>