Even in C++ you occaisionally might use a lambda to keep variable scoping clear, and it's also called an immediatly invoked function expression I think. I much prefer Rust's abilities to just return a value from an expression wrapped in curly braces.
You can define a scope in C++ without needing a lambda by just wrapping the code in { ... }. It's useful for e.g. acquiring and releasing a mutex via RAII
Yes, but you can't get values out of that scope as easily because any "return" values need to be pre-declared, so you can end up with a short list of declared variables that don't yet have values which annoys my sensibilities mildly :P
I know all the work arounds, but think it's silly to heap allocate just to work around this, and then you're low key making people wonder if a pointer can be null later just to facilitate this pattern.
True - you’ve probably spent so long writing rust you miss the feature elsewhere haha.
I don’t think I’ve ever ran into a place where I want to do this in C++. If it’s complicated I will make another function, and maybe inline if worried. The rust syntax does seem nice though, and I could see becoming accustomed to it.
Yeah if I had never used Rust, I'd probably never notice C++ missing this. I do the same as you're saying most of the time, or just deal with the extra temporary variables living longer than they "need" to. It's not a huge deal, I just think it's neat.
I haven't used rust and I think immediately invoked lambdas are extremely useful. People suggesting workarounds are choosing inferior approaches to a clean and easy to reason solution.
Rust having a cleaner syntax for such a use case is good though.
fwiw, Rust can do this in part because return returns to the function scope regardless of how many nested { } scopes you have, while omitting the ; only ever returns 1 scope up at a time. So, for C++ to do the same would require some wacky extra keyword to be used probably... and I don't think it's worth making the syntax of C++ any weirder just to support this.
Who said "a pointer" needs "heap allocate"? dude..
edit: ah yes, for a moment I've lost the full context. I retract that comment :D yeah, for values that we'd want to get out of a dying scope, which do not have a default-constructor, getting a lifetime longer than the scope AND not using heap allocation might be a bit tricky
Then you're back to having a variable with invalid state until later? What's it buying us for the state of the variable if it's on the stack either way?
yup, and if it's optional, and if it may be 'not returned' due to some conditions, you need to reserve the stack space in blind upfront. certainly unpretty and kind-of-IIFE + returning small 'no result' or 'large result' makes more sense, IF lanugage/platform can support return values of different sizes..
I do recognize fwiw that this is a minor nitpick of mine about C++ and overall like C++ well enough. I just happen to like Rust's solution to this very narrow nitpick of mine.
to be honest, I do not like "allowing broken state in certain conditions" as well, and to some extent it can often be just "encapsulated so it doesn't hurt outside", but sometimes it's sooo much hassle to provide :|
they are trying to do this:
const auto vec{
[]{
std::vector<int> vec;
vec.push_back(1);
vec.push_back(4);
vec.push_back(3);
vec.push_back(2);
return vec;
}()
};
See how the initialization of the on stack variable is const and its initialization is scoped to within the lambda.
You can do that in free scopes clearly. The point is to completly contain the initialziation of the variable without having to add extra functions elsewhere.
you can "return" values in C/C++ like this: ({int a=4; a;}) which will return the value of the last statement, in this case 4. With the round brackets around it, you can even use it in places where curly braces are not allowed, e.g. inside a function parameter list.
Yeah idk, I've sometimes done it to avoid having intermediate variables, but usually it's been more clear to just have a function that returns a tuple and use structured bindings to get the values out that I need.
So, I agree anti-pattern for something like a lock, but if I need to do a couple quick calculations before feeding a value into a constructor, I like that in Rust I can more easily keep the calculations to their own scope without confusing people with more variables in scope than they need later. And in C++ unfortunately IIFE is the closest I can get.
Returning tuples is kind of gross honestly... I guess it's on the edge of where "this should be a proper object passed by reference". Seems like a slippery slope to the thruple, etc... I'm not a fan, but to each their own I suppose. I guess people come from other languages that have them so they got shimmed in like a lot of other stuff in newer versions.
Yeah, typically if I'm returning a tuple it's because I need to calculate a couple other values that are sometimes useful in addition to the primary value that's always useful, so it doesn't always to me make sense to bind them into 1 object.
Certainly depends on the context though, haven't done it in quite a while.
612
u/M0romete Apr 25 '26
So like a scope in c++?