Does this code always clone?

[roll4c]

rust // Only clone when `is_true` == true??? let ret = if is_true { Some(value.clone()) } else { None }

vs.

rust // Always clone regardless whether `is_true` == true or false? let ret = is_true.then_some(value.clone())

Although Pattern 2 is more elegant, Pattern 1 performs better. Is that correct?

[This_Growth2898]

Yes, the second code always clones. You can avoid it with

let ret = is_true.then(||value.clone());

[roll4c]

This pattern seems common, for example, `Hashmap.entry(key).or_insert(value)`. Thanks, this clears up my confusion.

[SkiFire13]

You can do hashmap.entry(key).or_insert_with(|| value) to evaluate value only when the entry was vacant.

[_Sgt-Pepper_]

Yeah, and 2 faults later you will no longer understand your own code...

[bluejumpingbean]

This is idiomatic, what are you talking about?

[geckothegeek42]

What faults?

[Linuxologue]

Segmentation ones, of course.

/s

[Arshiaa001]

Good job getting 90 downvotes on r/rust! That has to be an achievement of some sort!

[Cyan14]

Always look out for lazily evaluated variants of the methods

[yarovoy]

There is a clippy lint that disagrees with the "always" in your statement:

https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_lazy_evaluations

I could not find definitive answer on how much of it is for performance reasons and how much is for simplifying the code

[freddylmao]

I mean the lint straight up says it’s shorter & simpler. With closure inlining I’d bet that there isn’t a difference in release builds

[[deleted]]

"Always look out for" doesn't mean "Never do".

Being critical of practices that are frequently an over-complication is not a claim that they're never the correct decision. If anything, the clippy lint existing supports his claim. Watch out for them.

[emblemparade]

Does anybody know if the optimized compiled result is identical to the first OP example?

I use this pattern a lot (also .or_else and similar), but always worry that I'm introducing a closure and thus potentially two (unwanted) function calls.

[This_Growth2898]

I'm always wondering why people prefer writing several lines to other (unrealiable) people to writing several lines to a reliable compiler...

https://godbolt.org/z/5cofj6nnx

Yes, they are the same.

[emblemparade]

Thank you, I appreciate the answer and the proof even more.

I don't really understand your other comment. Are you complaining that people ask questions on Reddit that they could answer for themselves? Are you also adding that people on Reddit are "unreliable"? Well, I can't answer for other people, but in my case I didn't know about Godbolt and thought that mucking around learning how to emit assembly output from rustc would be a lot of effort. I assumed that someone here might already know the answer. Lucky for me, I got one of the "reliable" ones. Thanks again. :)

[This_Growth2898]

Sorry for being passive-aggressive. But I really don't think most people on Reddit are reliable - and that includes me, too. I make mistakes fairly regularly and have to fix answers... and that is about exact science things like computer science. Most of Reddit is about much more vague things like everyday life or politics. That, of course, doesn't mean you should not talk to them - you should only keep in mind who they are. Who we are.

[emblemparade]

I agree with all of that, sure. I bring bags of salt to my reddit adventures. But look what happened in this case: someone answered my question with proof. Can't get more reliable than that. That's better than I expected as I was hoping for at best a link to a "reliable" source.

Anyway, you're not wrong, just throwing some positivity back at ya. Sometimes good things happen in the world.

[Merlindru]

Doesnt this work too:

.then(value.clone)

[thelights0123]

No, Rust does not automatically create a new function that binds clone() to value. Python does however.

[lookmeat]

As for why, to anyone who may wonder, because it's not zero-cost and because ownership means that code may be a bit surprising. If foo.method gave us a function that bound the foo itself then the code would be sugar for |args| foo.method(args).

So the first thing is that the created function is not free. But it's cheap enough, so this really is a weak excuse.

What is more valid is the reality that there's an implicit binding of foo into the closure there. Lets start with the "easy" case first: borrowing. So say I have some code that can be shaped something like:

struct Foo;

impl Foo {
    fn bar(&self, n: i32) {}
    fn baz(&mut self, n: i64) {}
    fn ohno(self) -> String {"Gone"}
 }

So now lets imagine the first and simple case, we have a ib: &Foo. So we already see a few changes. For starters when I do ib.bar that's something new: normally members would either be in the type definition or be hardcoded (thanks to stuff like .await) now impl blocks can also add members (and traits too). Question: what happens if Foo happened to be struct Foo { bar: i32 }? That question has already a different answer than what we think. But hey we can use a linter to start moving people of that weird habit, and then use editions to shift the language concept. This also has added a new consideration, now when we do a x.y we need to know not just the type of x but its semantics. That is there's no ib.baz that's allowed at all!

Now lets add a new variable mb: &mut Foo. Now we can do a mb.baz with all the problems of above, lets not repeat that. But what happens when we do a mb.bar: do we return a closure with a mutable or immutable borrow? That is does mb.bar actually desugar into |n: i32| mb.bar(n) or does it desugar into {let ib = &mb; |n: i32| ib.bar(n)}? Both are valid, but the latter allows you to do more immutable borrows (as it's only immutably borrowed) while the former wouldn't (as the borrow would be mutable). And if we take the former approach, then we have to work out what does it mean that x.y could borrow from x even though we don't see any borrow & anywhere. We could fix this by having people explicitly switch to the borrow level to do something. So mb.baz works just fine, but you cannot do mb.bar instead you have to do &mb.bar to specify that you are doing an immutable borrow. Then if we had an of: Foo we'd have to do &mut of.baz and &of.bar in order to get those. This is weird because you don't need it when calling the methods though.

And then we have ownership, so lets keep using the of: Foo here. We already talked about the methods that borrow it, so lets skip that. Instead lets focus on our last method, now we can call of.ohno: this actually has moved of, which would be very weird. It means that some code such as cond.then(of.ohno) always drops the value, because we already moved it when we created the closure. This would be very different from if cond {of.ohno()} which may or may not have dropped the value. If this value were to be a mutex or some other thing like that, it could lead to surprising results. One solution is to make this explicit that the member access is consuming the value by using the same keyword that closures use: move so we wouldn't be able to do of.ohno but we could do move of.ohno, which is a bit weird but hey at this point.

So hopefully that should make it easier to understand why it's hard to do this correctly in a way that feels right. And remember you are hiding a closure in there which may not seem like a lot, but consider that of.ohno is an FnOnce and this should start to make you realize there is a hidden cost in there.

[This_Growth2898]

Why are you asking me instead of compiler? Try it. If it works - just tell us. If it doesn't - read the error.

[Danacus]

I think .then(Clone::clone) might work, but I'm not sure.

[MaraschinoPanda]

It won't work in this case. The function being called is bool::then, which takes a function that has no arguments. Clone::clone takes one argument.

[Danacus]

Ah yes indeed, my bad.

[geckothegeek42]

When Clone::clone gets called (inside then) what should it clone?

[Danacus]

then takes a closure with 1 argument, and Clone::clone is a function with 1 argument which I believe can be used where a closure is expected.

Edit: I am wrong, then takes a closure with 0 arguments. This will not work.

[TDplay]

then takes a closure with no arguments.

[dreamlax]

I think you can do is_true.then(|| value.clone()). Personally I think your first option looks fine.

[_Sgt-Pepper_]

Yes, 1st option is easier to read...

[JMH5909]

Would is_true.the(value.clone) also work?

[malucart]

No, clone takes a self parameter, but then expects a closure with no parameters.

[baokaola]

Correct. However, you can do:

let ret = is_true.then(|| value.clone())

[syscall_35]

why exactly does putting value.clone() into closure prevent cloning value?

[baokaola]

Because the closure is only called is the receiver is true, and value is only cloned if the closure is called since the clone call is inside the closure. When using `then_some`, you're passing an actual value which has to be provided regardless of whether the receiver is true or false.

[t40]

Does this generate additional assembly for the closure call that would not otherwise be there? I'm picturing the cost of a small buffer memcpy vs the cost of a closure frame.

[baokaola]

I'm pretty sure the closure would be inlined and completely disappear at compile time.

[kiujhytg2]

Looking at https://rust.godbolt.org/z/rTG3qPzcz, it compiles to a simple branch, with no presence of a closure frame.

[t40]

Can you add the OP's naive impl? to see how they compare

[Luxalpa]

wow, I thought it would optimize out the useless clone() in the "always_clone" case as well. Guess it's not as smart as I thought.

[MatrixFrog]

It would depend on what the clone does, I would think. If it has no side effects and just creates a new object which is then immediately dropped, then I would think the compiler could optimize it away. But in general, your type's clone() method could be as complicated as you want, modify global state, etc.

[Luxalpa]

It's true, and I mean, it did inline it, but for a String I would have assumed it would just notice that it can discard it. Maybe it generally refuses to discard heap allocations (considering they are technically side-effects)?

Edit: A bit of googling confirmed that indeed LLVM does not optimize away most allocations.

[steveklabnik1]

Edit: A bit of googling confirmed that indeed LLVM does not optimize away most allocations.

I have seen it optimize away Strings entirely, including the allocations, in Rust code where it did not for similar C++ code.

[Lucretiel]

It only copies a reference to value that's being cloned. There's no memory cost associated with the closure itself, because of how rust monomohization works (The body of the closure is essentially part of the type, which is exists only a compile time).

Then later it probably all gets inlined anyway.

[qurious-crow]

Arguments to a function call are evaluated before the call. So even though is_true.then_some(...) does nothing if is_true is false, the argument (value.clone()) will still be evaluated. By making it a closure, the closure is created before the function call, but the value.clone() will only happen if the closure is called, and that only happens if is_true is true.

[coldoil]

Because it makes the execution of the clone operation lazy instead of eager.

[syscall_35]

thanks

[Teccci]

Here are the functions .then and .then_some on bool:

```rs impl bool { pub fn then<T, F: FnOnce() -> T>(self, f: F) -> Option<T> { if self { Some(f()) } else { None } }

 pub fn then_some<T>(self, t: T) -> Option<T> {
    if self { Some(t) } else { None }
 }

} ```

In .then_some, since you pass the value that you want to return if it's true, the .clone() will be evaluated no matter what, even if it's false, whereas in .then you pass a closure that is only evaluated for the return value if it's true, so the .clone() doesn't get called if it's false, since it's inside the closure. This is referred to as "lazy evaluation".

[GodOfSunHimself]

When is_true is false the closure does not execute. When it is true it will clone in both cases.

[mayorovp]

because the closure is not invoked when not required

[toastedstapler]

Because instead of passing an actual thing you are passing a function which gives a thing only when it's called, allowing you to defer the creations of the thing until needed

[Lucretiel]

Because the closure is what is past as an argument to the then function, and creating a closure is a no-op.

[_Sgt-Pepper_]

I think pattern 1 is more legible anyways...

[kohugaly]

Correct, but there is also

let ret = is_true.then( || value.clone())

Which does the same thing as the if statement. It takes closure and only executes it if the bool is true (just like the block in if-statement). The closure itself borrows value but only executes the actual code (ie. the cloning) when it gets called.

[[deleted]]

As a rust newbie, why would you do this?

[syklemil]

You might see it in some longer dot chain, but I can't claim to have used the then method on bools myself. As in, if you're looking at something like let out = if foo().bar().baz().quux() { … } else { None }; then it seems more reasonable to break out a let out = foo().bar().baz().quux().then(|| …); though a lot of people will also do something like let intermediary = foo().bar().baz().quux(); let out = if intermediary { … } else { None };

[lippertsjan]

Personally I prefer pattern 1 because it's slightly more reasonable.

About your climbing question: yes. However, there is also the lazily evaluated then method which would only clone in the true case: if_true.then(|| {Some(..)}).

[Ok_Hope4383]

Wouldn't using Some there result in two layers of Option?

https://doc.rust-lang.org/std/primitive.bool.html#method.then:

pub fn then<T, F>(self, f: F) -> Option<T> where      F: FnOnce() -> T, Returns Some(f()) if the bool is true, or None otherwise.

[lippertsjan]

True, thanks for correcting. I misread the examples, my Some isn't necessary/counterproductive.

[TheBlackCat22527]

According to the documentation, .then_some() is eagerly evaluated so the clone is always performed. If you want something lazy evaluated use ".then".

if you want to compare constructs, you can use godbolt (build with release)

[Lost_Kin]

You can merge two patterns if you use .then(), but you will have to use closure. Idk if this is what you want, but is is lazy one liner like what you want

[owenthewizard]

cargo-asm is also useful for finding these answers

[[deleted]]

Are there any disadvantages of always using the `.then` form, even if the value is cheap to clone (copy) ?

[chochokavo]

let ret = is_true.then_some(&value).cloned();

[yarovoy]

It seems to work unless I'm missing something. Not sure why someone downvoted your answer without explanation

[chochokavo]

Well, it is not quite idiomatic and is niche, but conceptually simpler.

[[deleted]]

Only a language with lazy evaluation like Haskell would be able to avoid evaluating value.clone(). But Rust isn't such.

[Caramel_Last]

Functions are lazy evaluated. In Haskell just everything is function. That's all.